Extension talk:GeoData/Flow

Previous page history was archived for backup purposes at Extension talk:GeoData/LQT Archive 1 on 2015-07-10.

i see that in Wikipedia's page the coordinates are automatically showed in the upper right of the screen.

i couldn't understand how to do that on my site www.wikimilano.it

I would recommend to refrain from this idea.

It has been a dirty hack about 2004, and it is causing problems over problems.

There is no gap left in the interface for such coordinates. Therefore the hack is hoping that it does not cover any other element nor text. But the hack has no eyes and does not know whether there is a gap or not. It is a nightmare. Skins are changing, and for every skin version and amount of text a small place needs to be found. This does not work with mobile nor App.

After patching up to the latest version of Mediawiki (1.38.4) I tried updating my PHP from 7.4 to 8.1 and everything seems to work great... except for one error:

Deprecated: Return type of GeoData\CoordinatesOutput::jsonSerialize() should either be compatible with JsonSerializable::jsonSerialize(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /var/www/my.wiki/public_html/mediawiki-1.38.2/extensions/GeoData/includes/CoordinatesOutput.php on line 141

Does anyone know what's causing this and how to correct it? (Or do I just need to wait a while longer to go up to PHP 8.1?)

1.38 does not support PHP 8.1 yet. Though if you want to manually apply the patch, the 1.39 patch for this issue is in phab:T311919

At the very bottom of LocalSettings.php, I've set $wgMaxGeoSearchRadius = 30000; however, the effective search radius is still the 10km default.

I've manually passed coordinates to the Special:Nearby page, and listings will show if 9.9km away, but disappear once I specify a coordinate slightly further away.

I've kept all other defaults and I only have two georeferenced locations, so the $wgMaxCoordinatesPerPage setting shouldn't impact anything.

Are there any known bugs, additional settings I should change, or a hard codded max that I can't exceed? Ideally I would like no max radius if this is possible, but I'll be happy with a larger max radius if I can get one.

I've included several places with GPS coordinates in my page using Template:Coord. I've installed the extension GeoData.

When I include {{GeoGroup|mapframe=yes}} in my page, all I get is the output code of the template, not an actual map.

"<mapframe height="200" frameless="1" align="center" width="290">[

{"type":"Feature","geometry":{"coordinates":[-1.777979999999999893844915277441032230854034423828125,55.56616999999999961801222525537014007568359375],"type":"Point"},"properties":{"description":"55.56617°N 1.77798°W","title":"Adderstone Hall","marker-color":"5E74F3"}}," etc. appears on the screen.

I'm not getting any notification that I'm missing any templates or modules. When I put the same code into my sandbox on Wikipedia, it works fine.

I feel like the missing piece is that my install of mediawiki needs access to data in Wikibase, but I'm not sure if I need it locally or if I can query from wikidata. I have Wikibase installed, but I'm not sure what exactly to do with it.

Can someone just give me a next step so I know what I need to research. Thanks.

I understand now that I need the Kartographer extension. I've installed that along with the JsonConfig extension, but there doesn't seem to be any way to get them working on my own Mediawiki install.

Now I have the following problem: I have the Near Near feature, i.e. GeoData. I have written Geodata nearby and true position LocalSettings.php together and came to my wiki nearby function. But now when the king "show nearby articles," it says, "There's a problem with Nearby. Try updating the location." What to do?

Hi guys. I've been playing around with the API on en.wiki. and have a question. By default any secondary coordinates in the API output get labelled with the name of the article, which isn't necessarily very helpful. However WIWOSM is managing to extract the HTML anchor names for secondary coordinates on eg a list article of listed buildings in a county or the junctions on a motorway. I can't see how to do that via the API, am I missing something or is WIWOSM doing something clever that isn't available to mere mortals (short of parsing the list article directly)? TIA Le Deluge (talk) 14:58, 24 March 2020 (UTC)

Wiwosm uses screenscraping, it doesnt use this extension. Ive been looking into this a bit to see how to bring everything together, increase consistency and reliability, but its a big set of work that needs to happen in all prts of map support.

OK, no worries. Looking at the UK, the biggest one seems to be the lists of listed buildings which use a template which presumably has scope to be helpful, also the lists of place names and to a lesser extent eg junctions on motorway articles. In principle I guess you could templatify those and it would cover the vast majority of secondary coords in the UK, even if you'd need something cleverer to do absolutely every point. As an aside, congrats and thanks to everyone who's worked on these APIs, they've come a long way since I last looked at them years ago.

This is my site installation

Product	Version
MediaWiki	1.32.0
PHP	7.2.17-0ubuntu0.18.04.1 (apache2handler)
MariaDB	10.1.38-MariaDB-0ubuntu0.18.04.1
ICU	60.2
Elasticsearch	5.6.16

this is the LocalSettings.php configuration

wfLoadExtension( 'GeoData' );

$wgGeoDataBackend = 'elastic';

and this is the (partial) output of update.php script

...geo_tags table already exists.

...geo_killlist doesn't exist.

...coordinates are already DECIMAL in geo_tags.

When I try the new GeoData parser function (taken from Extension Page example):{{#coordinates:primary|26|04|N|178|46|E|}}

I get this Fatal error

Fatal error: The format of the coordinate could not be determined. Parsing failed.

What am I missed?

Any help is greatly appreciated

Do you have the 'Maps' extension installed? If so, this will cause the error.

Yeah, they both provide the #coordinates parser function:

• Extension:GeoData ...adds a new parser function, {{#coordinates:}}, that saves coordinates to the database.
• Extension:Maps ...provides the #coordinates parser function which allows conversion between all supported coordinate formats.

If you don't care about the GeoData part of this, you can edit Module:Coordinates on your own wiki, find the part that says this:

local function coord_wrapper(in_args)
	-- Calls the parser function {{#coordinates:}}.
	return mw.getCurrentFrame():callParserFunction('#coordinates', in_args) or ''
end

and replace it with this:

local function coord_wrapper(in_args)
	-- Calls the parser function {{#coordinates:}}.
	local result = mw.getCurrentFrame():callParserFunction('#coordinates', in_args)
	if string.find(result, "The format of the coordinate could not be determined") ~= nil then
		-- We wanted the #coordinates parser function from Extension:GeoData, 
		-- but we got the one from Extension:Maps instead :(
		result = nil
	end
	return result or ''
end

Thanks so much.

I'll give it a try.

I think Extension:Maps should opt to change the name of its function to something more relevant to its function, and clear the way for using both extensions simultanously.

That would be handy!

If "#coordinates:" gives us an easy way to write primary coordinates into the database from a template on a page, then what's the corresponding way for page templates to read the information out again elsewhere on the page?

Presumably there's some way to do this, perhaps some "Magic Words", like LAT and LONG that would let us access this info from elsewhere in the page in a standardised format, but I'm having trouble finding any info on how to do this.

Can someone confirm that this data can be accessed from within the page?

From the documentation, I assume that the data can be accessed through the API only. I think that being able to access it by using a parser function would be great, and would eliminate the need for the double storage of the data in another retrieval system, such as SMW. Of course integration between the two would be magnificent, but let's hope for little.

Is there no support for height data? I work in a museum and tourist information point that's ''underneath'' a major railway station terminus forecourt. People walk out of the station building into the outdoor cab rank, and latitude/longitude would tell them that they were inside the museum. Location data should be able to tell them that the "invisible" museum is twenty feet straight down, below their feet, and they they need to scout about for a way down.

Similarly, the station is built into the side of a steep hill, and we get a steady stream of lost people coming in from the road outside looking for it, who don't realise that the station is a couple of storeys up the the air, above the brickwork in front of them.

I appreciate that altitude isn't as important as lat/long, but it seems odd to have no way of entering the data for the cases where it matters.

SSL is required in order for Chrome to allow a website to ask for a user's location.

I have similar problem.

From MW 1.29, Nearby did not worked. there was a parsing error at #coordinates.

• current version of my private wiki : 1.30.0
• I'm using SSL

I think semanticmediawiki Maps have something to do with parsing error. After I remove SMW maps, a parsing error was not happened and Nearby worked.

Any one who have idea to fix this, let me know.

Thanks

I can confirm that GeoData conflicts with Maps extension - both define `cooridnates` parser-function and it seems like the one from Maps overrides the one from GeoData