Location field precision

[chuqtas]

I notice many regional operators are listed as location 001 (worldwide). Is there benefit to submitting alterations to limit these to the countries in which they operate, even if there is no naming conflict with other regions? Or is it unnecessary complication and a waste of time?

Followup question - are there any other non-country codes (like 001) that can be used? e.g. eu for Europe?

[bhousel]

I notice many regional operators are listed as location 001 (worldwide). Is there benefit to submitting alterations to limit these to the countries in which they operate, even if there is no naming conflict with other regions? Or is it unnecessary complication and a waste of time?

Hey @chuqtas it's definitely welcome to submit changes to make the locations better defined 👍

This project depends on another project called country-coder, which supports identifying places by their country, region, or wikidata code.

The full list of supported codes is here: https://ideditor.codes/

[chuqtas]

Thanks, I'll endeavour to update some of those!

Interestingly enough there is a separate code for my home state (Tasmania - au-tas) but none of the other Australian states. Usually we're the last to get things, what a nice change :)

I've also just submitted a pull request using the lat/long format (or should I say, long/lat - it threw me for a bit!) - not knowing exactly, how it worked, I've basically copied the format from another city. I guess I'll find out if the pull request is approved or not!

[UKChris-osm]

Hi @chuqtas

001 is the default location, but if you're able to be more specific with it then please do :)

When using a single long/lat combo, the location will create a 25km radius around that GPS point. You can check your use of a GPS location using ideditor.github.io/location-conflation/, as well as using the nsi.guide for each entry, such as that for City of Launceston. If you're happy that the charging stations will all fit within the 25km radius then that's all fine, but if you think it's too small then I would suggest changing it to "au-tas"

This project also allows for the use of custom ".geojson" files to define an area within the map for certain entries. These can be found (and uploaded to) the features folder. I've recently added ".geojson" files for Australia, which you can use if you only want to target one region.

I hadn't realised "au-tas" was already available, so I've deleted the custom "au-tas.geojson" file.

[chuqtas]

Thanks for the info @UKChris-osm!

[Edit: I wrote the section below before noticing I had unintentionally skipped over the paragraph in your comment about the Aus geojson files. Rather than delete it, I thought I'd still leave it up, as it is still relevant in the context of ensuring different projects describing the same thing use consistent data!]

I notice that a different project (https://www.electricitymap.org/ - GitHub repository https://github.com/tmrowco/electricitymap-contrib), has separate geojson files for Australian states. I'm not sure if they can be used in this project though, since they are designed around connected electricity grids. In most places the state borders and grid regions coincide, but there are minor differences (Australian Capital Territory, some off-shore islands, etc). The USA in that project uses regions that are (for the most part) visibly distinct from US state borders!

I was trying to think if there was an open repository of open existing geojson files, then realised we're talking about OpenStreetMap here :) are the relations from OSM itself not able to be exported/used for this? (Example: Victoria - https://www.openstreetmap.org/relation/2316741)

[UKChris-osm]

I have asked about a central repository for such regions, rapideditor/country-coder#34 as I think it would be a good idea, as well as a discussion about using relation borders #4784 and it may happen one day.

I think the downside with relation borders is that they are very precise, and use large amounts of gps points to draw each border, meaning they can take up quite a bit of space and processing power for the user, and I think the dev's of iD want it to be as streamlined and lightweight as possible, which is fully understandable.

But with ISO 3166-2 sub categories (e.g ISO_3166-2:GB, ISO_3166-2:AU, etc) it wouldn't surprise me if eventually all these are usable in some form.

I've also been using the ISO 3166-2 sub category as a name for each .geojson, such as those in Australia, so in theory they could be imported automatically at a later date if another project wanted them.