Recently, it was brought to my attention that the tag ref:ine is used both in Spain and Portugal for different purposes.
After some discussions both with mapper Hugoren Martinako and in the Portuguese community, there’s no clear approach to this.
Some propose the use of a namespace like ref:PT:ine / ref:ES:ine, like the examples here, which has the inconvenient of changing tags that are used thousands of times in both countries.
Others suggest specifying the differences of use of ref:ine in English, Spanish and Portuguese wikis.
At 82K use a pretty monster of a job to split them, the graph inferring though this was several large volume type of imports to begin with and little activity inbetween.
I did it yesterday actually, like a first step to make the difference. Honestly, we have some software developments where the key is being used, so it’s not only about the renaming in OSM (pretty straightforward), what back me out the most are the apps updates.
I know that in the long term the use of the country-codes inside the key would be a very good solution, but as it was previously mentioned, since there are no overlaps, geographical queries are enough, IMHO.
Not quite getting your point. Apparently the issue is, that ref:ine is used in at least two different contexts. What you are saying makes only sense if all apps out there do geographical queries already. I would rather think that’s not the case. So the apps need to update anyway and then I would think the change from ref:ine to ref:ES:ine might be by far easier than implementing geographical queries, not talking about the additional cost these queries cause to the servers.
Yeah, though your main argument are the required updates to apps, which I believe need to be done anyway. Either by changing the OSM-Key or by implementing a geographical limitation to validity of the existing key.
Let’s take jOSM as one app, which offers to go to the item specified in the value of the key of that service. How that should work, if there are multiple services linked to that key? Remember jOSM usually does not have any boundary information available.
Services build on OverpassAPI or having other db’s in the background need to implement the geographical limitiation.
Like instead of a simple:
[out:json][timeout:25];
nwr["ref:ES:ine"]({{bbox}});
out geom;
it would be:
[out:json][timeout:25];
area(id:3601311341)->.searchArea;
(nwr["ref:ine"]({{bbox}});)->.ineBbox;
nwr.ineBbox(area.searchArea);
out geom;
We are aware of that, the current apps are working properly. On Key:ref:ine - OpenStreetMap Wiki you can find some overpass validation queries, and notice the area["ISO3166-1"="ES"]->.searchArea; statement.
In case of a future development, we could reconsider this, but for now there’s no need to overcomplicate things since everything is already working. Just making that point clear so we keep it in mind going forward.
The only problem I see with this is giving the impression that data shouldn’t be changed/corrected/bettered because of third party apps and renderers, when it should be the other way around. This is my main doubt.
Anyway, I’m OK as it is now if the absence of country overlaping is not a problem when accessing the data.
You will have issues if you do not have a complete country boundary available from Spain and/or Portugal. If you just have one of those data-objects, you can’t derive where it belongs to.
I think that the country prefix is a false solution because what makes us believe that there will be no collision of the same abbreviation in the same country? There are two bus networks with the same name in France.
I think it is preferable to do as other projects do and describe how we differentiate between them.
The other major drawback of prefixes is that it is impossible to guess the key when you are in the field, which should be the basis of OpenStreetMap.
For example, if you want to enter the reference for a powe=substation in France during a ground survey, it is impossible to guess the key with all the suffixes, whereas it would have been practical to put the ref in the ref key, the operator kew already give the info about the logic used to find the correct key using the wiki
Which two? You can add a region suffix.
If you don’t know, or the application has no preset, you can always simply add ref= first. Do it later, or let others help you. A ref:*= can show a shared database between different features, ie all power= , not only for =substation or others individually. Another thing to consider is ref:*= being used for external databases not signposted, to contrast and reserve the ref= for what’s signposted and referred to there. https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity=parking_space#Shouldn’t_ref_refer_to_the_number_of_the_parking_space_itself_than_on_3rd_party_values?
That being said, if there is only one possible database dedicated to a feature always signposted at them, the benefit of using ref:*= is lower. ref= / *_ref= could be sufficient.
It’s better to have two similar abbreviations under ref:ES than… ref. In the (rare) case it happens, at least we know what country it’s from and we can try to find solutions, such as
I disagree on this. First, the prefix reduces the coverage and by this also the group of people you need to align with. Like keys in ref:ES:* you only need to discuss within the Spanish community. Second, due to the smaller group of people, they most likely know duplicate keys and it’s easily possible to come up with a different key.
Arc-en-Ciel : Haute-Garonne (In the meantime, the network has been renamed twice and the problem no longer arises at this level) and Nord
So if you want to map an element of the network, not only do you need to know that there is a national prefix, but you also need to know that there are two in the country, and you need to know the extent of the second network in order to guess whether the chosen solution was a prefix linked to the department, or perhaps a prefix linked to the municipality or to the region? Unless the other network covers two countries, in which case it would be a European prefix? This kind of guessing game makes no sense.
In practice, if you want to use network to find information, the only thing to do is to search with a regexp and a geographical scope because the OSM network tag is unusable in this case with more than four different values depending on the contributors’ level of expertise in guessing games.
and in fact the mapper will lose the guessing games, because some choose to rename one of them into fr_arc_en_ciel, without any ground logic but only due to the dogma that value must be unique worldwide, which does not correspond to reality
However, since there had been a conflict previously, even in the case of a unique value at the national level, you should have known that there was a conflict, which meant that the networks in Département du Nord would probably have used a key such as network:FR:Nord=Arc-en-Ciel.
Of course “Ground Truth” is that both references are linking to a different database.
That would be only different if you only use ref for everything. But then you end up with a longer list of values and have no clue where they belong to and what they mean. In all other cases you need to check with wiki on how to add your specific referrer.
ref + operator tell you exactly what the ref corresponds to, without having to consult the wiki to find out that the real name of the network has been artificially changed to fr_arc_en_ciel, whereas the sign says ‘Arc en Ciel’.
The link between ref and operator works so well that it is used with confidence for mechanical edit.
The context here seems quite different to the original topic. Towns and villages tagged with ref:ine are not “operated” by the national statistics agency, it would make no sense to tag them as, say, operator=ine.
You’re right, it’s not exactly the same thing.
But ref:ine + the fact that the object is in a particular country says exactly the same thing as ref::ine without needing to convince every future ‘ine’ that they too must use a country prefix to avoid ambiguity, even when they are unaware that there is ambiguity elsewhere in the world.
In some cases, yes. In other cases you need to check maybe network or you need to query any kind of relation, which you might not have available in the data.
