Query on specific value of Geographical coordinate type property returns nothing

From semantic-mediawiki.org
[[Has coordinates::{{#coordinates:{{{koordinater}}}|format=dms}}]

Ahh, don't do that... The property annottaions already accepts all the formats, no need to reformat first. And if you do want to reformat, then I suggest keeping display and setting of the property seperate (ie setting it using set). Also keep in mind you can set the default display format of coordinates in annotations, so perhaps you don't need any wikitext for it at all.

the query returns with nothing

Hmm, it should...

"Fatal exception of type MWException" 

Need more info, for instance a stack trace.

21:01, 9 February 2013
Ahh, don't do that... The property annottaions already accepts all the formats, no need to reformat first.

Just changed it to take the coordinates without reformatting, and they were displayed the same, so I guess I just assumed it wouldn't without even testing first. :) Didn't affect the query problem though.

Need more info, for instance a stack trace.

Here is the complete stack trace:

There is no result format for 'map'.

Backtrace:
#0 /customers/a/0/d/somecustomer/httpd.www/extensions/SemanticMediaWiki/includes/params/SMW_ParamFormat.php(143): SMWQueryProcessor::getResultPrinter('map')
#1 /customers/a/0/d/somecustomer/httpd.www/extensions/Validator/includes/definitions/ParamDefinition.php(719): SMWParamFormat->formatValue('auto', Object(Param), Array, Array)
#2 /customers/a/0/d/somecustomer/httpd.www/extensions/Validator/includes/Param.php(213): ParamDefinition->format(Object(Param), Array, Array)
#3 /customers/a/0/d/somecustomer/httpd.www/extensions/Validator/includes/Validator.php(341): Param->format(Array, Array, Object(ValidatorOptions))
#4 /customers/a/0/d/somecustomer/httpd.www/extensions/Validator/includes/Validator.php(281): Validator->doParamProcessing()
#5 /customers/a/0/d/somecustomer/httpd.www/extensions/SemanticMediaWiki/includes/SMW_QueryProcessor.php(59): Validator->validateParameters()
#6 /customers/a/0/d/somecustomer/httpd.www/extensions/SemanticMediaWiki/includes/SMW_QueryProcessor.php(424): SMWQueryProcessor::getProcessedParams(Array, Array)
#7 /customers/a/0/d/somecustomer/httpd.www/extensions/SemanticMediaWiki/includes/parserhooks/SMW_Ask.php(38): SMWQueryProcessor::getQueryAndParamsFromFunctionParams(Array, 2, 1, false)
#8 [internal function]: SMWAsk::render(Object(Parser), '[[Has coordinat...', '?Has coordinate...')
#9 /customers/a/0/d/somecustomer/httpd.www/includes/parser/Parser.php(3250): call_user_func_array(Array, Array)
#10 /customers/a/0/d/somecustomer/httpd.www/includes/parser/Preprocessor_DOM.php(1083): Parser->braceSubstitution(Array, Object(PPFrame_DOM))
#11 /customers/a/0/d/somecustomer/httpd.www/includes/parser/Parser.php(3038): PPFrame_DOM->expand(Object(PPNode_DOM), 0)
#12 /customers/a/0/d/somecustomer/httpd.www/includes/parser/Parser.php(1136): Parser->replaceVariables('{{Koieboks?|nav...')
#13 /customers/a/0/d/somecustomer/httpd.www/includes/parser/Parser.php(370): Parser->internalParse('{{Koieboks?|nav...')
#14 /customers/a/0/d/somecustomer/httpd.www/includes/EditPage.php(2664): Parser->parse('{{Koieboks?|nav...', Object(Title), Object(ParserOptions))
#15 /customers/a/0/d/somecustomer/httpd.www/includes/EditPage.php(1738): EditPage->getPreviewText()
#16 /customers/a/0/d/somecustomer/httpd.www/includes/EditPage.php(401): EditPage->showEditForm()
#17 /customers/a/0/d/somecustomer/httpd.www/includes/actions/EditAction.php(51): EditPage->edit()
#18 /customers/a/0/d/somecustomer/httpd.www/includes/actions/EditAction.php(71): EditAction->show()
#19 /customers/a/0/d/somecustomer/httpd.www/includes/Wiki.php(427): SubmitAction->show()
#20 /customers/a/0/d/somecustomer/httpd.www/includes/Wiki.php(304): MediaWiki->performAction(Object(Article))
#21 /customers/a/0/d/somecustomer/httpd.www/includes/Wiki.php(536): MediaWiki->performRequest()
#22 /customers/a/0/d/somecustomer/httpd.www/includes/Wiki.php(446): MediaWiki->main()
#23 /customers/a/0/d/somecustomer/httpd.www/index.php(59): MediaWiki->run()
#24 {main}
01:12, 10 February 2013

Through the debugging feature, I've found the following:

I have a page where the coordinates were entered as "62.63664, 11.00655" and saved to the "Has coordinate" property. This makes the coordinates show on the page as "62° 38' 12" N, 11° 0' 24" Ø", and if I edit the page and show a preview, I can hover over the coordinates which appear in the list of properties on the bottom of the screen, and a small box says "Latitude: 62.63664 Longitude 11.00655" (in Norwegian). This is in perfect accordance with the values saved in the database table "wsmw_di_coords", containing the exact same values in the fields "o_lat" and "o_lon", as well as "o_serialized" containing the value "62.63664, 11.00655".

However! When I add the query {{#ask: [[Has coordinates::62° 38' 12" N, 11° 0' 24" Ø]] | ?Has coordinates | ?Name }} in a page, the debugging feature shows that the database call is: SELECT /* SMW::getQueryResult 194.19.124.36 */ DISTINCT t2.smw_id AS id,t2.smw_title AS t,t2.smw_namespace AS ns,t2.smw_iw AS iw,t2.smw_subobject AS so,t2.smw_sortkey AS sortkey FROM `wsmw_object_ids` AS t2 INNER JOIN `wsmw_di_coords` AS t0 ON t2.smw_id=t0.s_id WHERE ((t0.o_serialized = '62.636666666667' && t0.o_lat = '11.006666666667') AND t0.p_id='65') ORDER BY t2.smw_sortkey ASC LIMIT 51.

As you can see, there are seemingly two things that are off here. First of all, it seems to look up the latitude in the field "o_serialized" and the longitude in the "o_lat" field. Second, the values themselves are off, probably because of some precision problem when converting to and from float format and DMS.

The second part I'm hopeful I can work around somehow (I'm trying to display a list of pages with it's coordinates set within a defined distance from the current page, explained in the documentation, so as long as I can exclude the current page from showing in the list, it's fine). But the first is a real problem, because even when I change the query to [[Has coordinates:62.63664, 11.00655]] it looks up the right coordinates, but in the wrong fields in the table, and gets an empty result.

How all of this relates to the crash occuring when dropping the "|?Name" part, I don't know yet.

11:32, 11 February 2013
First of all, it seems to look up the latitude in the field "o_serialized" and the longitude in the "o_lat" field.

Interesting. I tried repdoucing this but ran into another issue... Anyway, I created Task T46933 to keep track of the issue.

the values themselves are off, probably because of some precision problem when converting to and from float format and DMS. 

Not a lot SMW can do about this. More the respnsibility of the Maps and Semantic Maps extensions. SMW 1.9 will be using Maps 3.0.x, which has a rewritten coordinate parser, in which some bugs are fixed compared to the one in Maps 2.0.x. Perhaps that will fix your problem.

If you just want to select on one exact value and always enter it in the exact same format (inc same spaces and stuff), you could ofc just store it using an extra string property. To ensure the format is the same you could use the #coordinates function in the way I recommended against. A rather big hack, but might work fine for you.

How all of this relates to the crash occuring when dropping the "|?Name" part, I don't know yet. 

Both these issues do not relate to the one for which you provided a stack trace.

09:23, 13 February 2013
Not a lot SMW can do about this.

No, I figured. Not a big issue, though. I just need a slightly different approach to what I want to do, and it isn't really much of a problem.

Both these issues do not relate to the one for which you provided a stack trace.

Are you sure about that? That's strange. Too strange almost, as the stack trace is from the error occurring when I omit "|?Name" from the query. I get the error message "Fatal exception of type MWException" when stack tracing is turned off, and the stack trace posted above when stack tracing is turned on. When I leave "|?Name" in the query, I get no error message, but it looks up the coordinates in the wrong fields.

10:09, 14 February 2013

The bug the stack trace is pointing out might be affecting the other two (yeah, we thus have 3), though it certainly is distinct from those two.

14:22, 16 February 2013
 
 
 

What version of SMW and SM are you using? I've seen thius error before and think I fixed it already.

08:53, 13 February 2013

SMW version 1.8, SM version 2.0.1.2.

I just realized something. When I try to run the query without "|?Name" it for some reason defaults to format=map. But there seems to be no defined format called "map", hence the error message on top of the backtrace: "There is no result format for 'map'." When I omit "|?Name" but include "format=broadtable" no error is returned, but it still looks up the coordinates in the wrong fields.

So there seems to be two bugs here:

1. A query for specific values of the coordinates property looks up the latitude and longitude in the wrong fields (o_serialized and o_lat, respectively, instead of the correct o_lat and o_lon).

2. When doing a query for specific coordinate values (EDIT: or just any page with coordinates set (i.e. [[Has coordinates::+]])) and only showing the coordinate values in the result, it defaults to the result format "map" which isn't defined. (EDIT: And a "Fatal exception..." error is produced.)

10:57, 14 February 2013
I just realized something. When I try to run the query without "|?Name" it for some reason defaults to format=map

If you just have coordinates in the result set, it will default to map yes. Name is not a coordinate, thus it defaults to table or whatever. Just set the format explicitly (though not map).

The other issue, which is not fixed yet on the latest dev version, has Task T46933.

14:26, 16 February 2013
If you just have coordinates in the result set, it will default to map yes.

Yes, I understand. That is not the issue. What I meant by the horribly phrased second point, was the following. When SMW, because of bug 44933, looks up the values in the wrong fields, it will naturally return a null result, as no entry matches the search strings. Here are a few examples of queries and their expected results, versus their actual results:

{{#ask: [[Has coordinates::62° 38' 12" N, 11° 0' 24" Ø]] | ?Has coordinates | format=broadtable }}

Expected result: An empty or "nonexistent broadtable". Actual result: A nonexistent broadtable.

{{#ask: [[Has coordinates::62° 38' 12" N, 11° 0' 24" Ø]] | ?Has coordinates | format=count }}

Expected result: The number zero. Actual result: The number zero.

{{#ask: [[Has coordinates::62° 38' 12" N, 11° 0' 24" Ø]] | ?Has coordinates | format=csv }}

Expected result: A link to a csv file empty of results: Actual result: A link to a csv file empty of results.

{{#ask: [[Has coordinates::62° 38' 12" N, 11° 0' 24" Ø]] | ?Has coordinates | format=map }}

Expected result: An empty or "nonexistent map". Actual result: A nonexistent map.

{{#ask: [[Has coordinates::62° 38' 12" N, 11° 0' 24" Ø]] | ?Has coordinates }}

Expected result: An empty or "nonexistent map", because it defaults to the map format. Actual result: A fatal exception error with the following as the top of the stacktrace:

There is no result format for 'map'.

Backtrace:
#0 /customers/a/0/d/somecustomer/httpd.www/extensions/SemanticMediaWiki/includes/params/SMW_ParamFormat.php(143): SMWQueryProcessor::getResultPrinter('map')

This seems to be a problem separate from bug 44933.

11:01, 18 February 2013