OpenStreetMap logo OpenStreetMap

Changeset When Comment
127256964 over 2 years ago

Hi,

I noticed you tagged a series of what appears to be historic dry stone shelters as amenity=shelter, shelter=basic_hut.

However, that tag is meant for true survival type shelters, usually including basic accommodations to sleep, like a bunk bed, and usually located in mountainous areas.

I think these historic (cattle/human?) shelters are better re-tagged to amenity=shelter, shelter=weather_shelter, as a more suitable tag for their purpose and build.

128246602 over 2 years ago

I wouldn't call widespread pretty much established tagging "a common mistake", rather the Wiki likely needs updating to reflect it.

There is quite a bit of undocumented established tagging, that really should be taken into account before assuming the Wiki is "right".

128246602 over 2 years ago

Notes *do* contain admin_level tags. In fact, almost all capital cities in the world have the admin_level=2 set on the node, and it is currently the most consistent way to get all country capital. For admin_centre role nodes, that may be part of multiple admin boundary relation, it is quite established tagging to add the highest level admin_level to the node, while the atual admin_level of the relations it is part of, will generally differ.

E.g. a country capital node may have admin_level=2 set, and subsequently be part of boundary=administrative relations with admin_level=2 / 3 / 4 / 7 / 8 or whatever.

124545262 almost 3 years ago

Hi,

In this changeset, you removed admin_level=2 from the Beijing node, despite it being the capital city of China, and added notes it should be "removed" if re-added. I think this is incorrect.

Essentially *all* other country capital nodes in OSM have admin_level=2 set to signify in a standard way that they are country level capitals, and this is used for cartography as well.

If the city has a lower "admin_level" in the country itself, that admin_level (e.g. "admin_level=4"), is usually set on the corresponding "type=boundary" + "boundary=administrative" relation.

So the relation's admin_level can, and usually will, differ from the corresponding and associated node's one in the case of country capitals.

Please review some of the other country capitals to understand what I mean.

I recommend you to re-add the "admin_level=2" tag, so that Beijing correctly shows up as country capital of China in maps that use this information, and remove the "note" tags, because there is currently no other tag to fully cover this particular aspect related to country capitals.

127066178 almost 3 years ago

Thanks for pointing out. This was an accidental error, I had intended to edit the node of Lomé, not the boundary relation.

This is now fixed.

71648140 almost 4 years ago

Hi Odiz,

I noticed that there are a lot of free_flying sites in Norway that you have been editing and that don't have any path connecting them to the outside world.

Now I don't know if it is common practice in Norway to stroll through wild forests and heaths to get to a take-off site, but I do think adding paths where they do exist, would add value to the data.

Still, I guess it is not uncommon that many will not have a formal path, as the usage of the take-off sites is likely only sporadic in a sparsely populated country like Norway.

102263854 over 4 years ago

"rever" should have been "revert" of course...

102263854 over 4 years ago

Hi Colin,

I personally do not consider the tagging of this island "inappropriate", considering what happened.

Establishing whether the decontamination rendered it truely safe to visit, I guess is hard, as people are likely still avoiding the island due to an abundance of caution, and it being private property, and varying opinions related to this.

The only reason I suggested you might pick this up, is that I consider the ultimate say to be with the local communities in these cases.

If you prefer me to rever it, I can do that for you, no problem.

102263854 over 4 years ago

I also don't mind if you revert the edit, if you feel that's more appropriate or the easier option to avoid discussions.

102263854 over 4 years ago

Hi Colin,

Feel free to do this yourself as part of the British community, if you know a more appropriate tagging. It is just a well known historic event.

Of course, this was bound to be a little bit contentious edit, as establishing the true safety is virtually impossible, considering the type of hazard, and no official guideline seems available (e.g. using the "Search" textbox on something like www.gov.uk or www.gov.scot doesn't turn up any reference to Gruinard Island).

Here in the Netherlands, we have the so called "pestbosjes", small patches of forest often situated well away of farm yards, where carcacesses of diceased sick livestock were buried before a national destruction law came into being in the 50/60's. They still pose a thread, decades on, if accidently not left undisturbed due to redevelopment.

43004896 over 4 years ago

Hi Marc,

Sorry to answer in English, but I can read and understand your question well enough.

As you noticed, I haven't removed these tree features, just retagged them to what I think in this situation is more appropriate.

I really personally feel that these kind of exceptional features (only very few buildings have true trees in them), should not be tagged with a main tag like natural=tree, without any additional information attached to them.

It is confusing to see trees appear on top of a building feature, suggesting a digitization error, even if this situation is becoming more common.

Using a main tag like natural=tree for these kind of exceptional features, will also mean that no cartographer will be able to easily filter them out, without resorting to some elaborate point-in-polygon automated check on every tree and building feature in OSM (which would be a pain to do on a global scale).

I feel the "indoor=x" tagging scheme is quite appropriate for this kind of feature, even if it is not currently rendered in the Default map. That is why I changed them to indoor=tree. This will still allow specialized (indoor) renderers to show the features, but not have the confusing tree features appear in every map derived from OSM's database.

Marco

97443695 over 4 years ago

Vermoedde al zoiets, volgens mij ben jij een te ervaren mapper voor een dergelijke fout. Het is nu in ieder geval snel opgelost.

Marco

97443695 over 4 years ago

Hoi padvinder,

Ik zag dat je in de Wimmenummerduinen bij Bergen aan Zee de tags voor een vogelkijkhut op een hele grote polygoon voor "scrub" had toegevoegd. Dit is echt "bad tagging practice", en ik wil je vriendelijk vragen dit niet meer te doen. Ik heb deze tags dan ook weer verwijderd.

Maak in plaats daarvan een nieuwe node aan op het punt waar de vogelkijkhut staat, of digitaliseer de outline van het gebouwtje (als het dat is), en voeg dan ook "building=yes" toe.

Happy mapping!

Marco

66879956 over 4 years ago

Hi bichlepa,

I noticed you added a very large amount of "viewpoints" in the vicinity of Endingen am Kaiserstuhl, that seem to be based on photo locations.

While I appreciate your specific photo based collection technic, that you also describe on your profile page, I would still like to kindly ask you to refrain from adding photo locations as "tourism=viewpoint" features.

While I understand that this is a highly scenic landscape, based on the aerial imagery and detailed cartography of the area, adding viewpoints every 50 meters or so, clutters up the map, and makes it really hard for e.g. professional cartographers to use OSM as a reliable data source.

OSM is not meant to document your photo yourneys, there are other platforms for that. I would therefor also like to kindly ask you to thin out and remove excess viewpoint in this area, and only leave the true "pearls" of the nicest spots as viewpoints.

Kind regards,

Marco

92517977 almost 5 years ago

Hoi Otto,

Dan zou ik het verder zo laten. Mocht je later nog meer informatie opduikelen, dan kun je het alsnog aanvullen met b.v. 'pumping_station=wastewater'.

Mvg,

Marco

92517977 almost 5 years ago

Beste Otto,

Ik zag dat je in het Amsterdamse havengebied verscheidene objecten, van wat ik aanneem dat (ondergrondse afval-)water pompstations zijn, had getagged met man_made=watermill. Die tag is echter alleen bedoeld voor historische watermolens. Voor moderne pompstations is er man_made=pumping_station. Ik heb deze objecten nu gecorrigeerd. Omdat ik echter niet precies weet wat er daar verpompt wordt, heb ik nog geen pumping_station=x tag toegevoegd. Misschien dat je dat nog zelf kunt doen: osm.wiki/Tag:man_made%3Dpumping_station

Marco

91814591 almost 5 years ago

Yes, you're right, I made a mistake here with a couple of bridges in the last few changesets. I'll correct them. It is of course metric ton here in the Netherlands, so I will remove the 'st' per Wiki for the changesets with error.

82840124 about 5 years ago

Sorry, a copy and paste went wrong, and I accidently inserted parts of the text twice. Please ignore double text errors in last post.

82840124 about 5 years ago

Ionvia,

Thanks for taking time to respond. I fIonvia,

Thanks for taking time to respond. I fully agree "Berlin is not a country", but it is the "country capital of Germany". I don't fully understand the reasoning you state of "admin_level" being related to government hierarchy, but that statement not being applicable to capital nodes like Berlin (don't they form an hierarchy as well?).

The Wiki page for "admin_level" also specifically states usage of "admin_level" in combination with the "capital=x" tag:
osm.wiki/Key:admin_level
"Usage": The admin_level=* values are also used for the capital=* and heritage=* tags."

So this seems to be a quite well established practice as well. I agree the "capital=2/3/4..." is listed as well on the "capital=yes" page, but this Overpass Turbo query seems to indicate the first tagging practice is the established one for now on capital nodes:

https://overpass-turbo.eu/s/VEh

I am just trying to wrap my head around what specific issue this causes in Nominatim that it lead to you wanting to remove a tag on a single node so common on all other capital nodes? It just doesn't make sense to someone not familiar with the inner workings of Nominatim like myself.

Most other country capitals, in fact almost all, seem to have the same admin_level=2 tag on the corresponding capital=yes node, so what is specific about Berlin and Germany?

What I am actually also wanting to say is that if we as community desire a change to the current tagging practice and think that from a technical point of view it is better to switch to:

"capital=2-10"

instead of:

"capital=yes"
"admin_level=2"

for all capital nodes, then maybe it is better to try and get some consensus on tagging mailing list, and then setup a project to change it wholesale (possibly through mechanical edit), instead of an apparently randomn change on a single Berlin node.
ully agree "Berlin is not a country", but it is the "country capital of Germany". I don't fully understand the reasoning you state of "admin_level" being related to government hierarchy, but that statement not being applicable to capital nodes (don't they form an hierarchy as well?).

The Wiki page for "admin_level" also specifically states usage of "admin_level" in combination with the "capital=x" tag:
osm.wiki/Key:admin_level
"Usage": The admin_level=* values are also used for the capital=* and heritage=* tags."
So this seems to be a quite well established practice as well. I agree the "capital=2/3/4..." is listed as well on the "capital=yes" page, but this Overpass Turbo query seems to indicate the first tagging practice is the established one for now on capital nodes:

https://overpass-turbo.eu/s/VEh

I am just trying to wrap my head around what specific issue this causes in Nominatim that it lead to you wanting to remove a tag on a single node so common on all other capital nodes? It just doesn't make sense to someone not familiar with the inner workings of Nominatim like myself.

Most other country capitals, in fact almost all, seem to have the same admin_level=2 tag on the corresponding capital=yes node, so what is specific about Berlin and Germany?

What I am actually also wanting to say is that if we as community desire a change to the current tagging practice and think that from a technical point of view it is better to switch to:

"capital=2-10"

instead of:

"capital=yes"
"admin_level=2"

for all capital nodes, then maybe it is better to try and get some consensus on tagging mailing list, and then setup a project to change it wholesale (possibly through mechanical edit), instead of an apparently randomn change on a single Berlin node.

82840124 about 5 years ago

Ionvia,

Can you explain a bit why you removed "admin_level=2" from Berlin's place node?

All other countries in Europe, and most in the world, have an "admin_level=2" tag on the node representing the country capital.

By removing this tag, there is no longer an easy way to distinguish country capitals from any lower level ones (state, province etc).

As a negative consequence of this removal, my maps no longer show Berlin as Germany's country capital, as I, and probably a lot of other map makers / cartographers, rely on the admin_level tag to distinguish capitals defined at different administrative levels. It is the only practically usable tag available for this at this moment.

I have the feeling that this removal is trying to fix the wrong thing, and that any problems with Nominatim require either a change in Nominatim, or more likely a change in the OSM boundary relations using the Berlin node as "admin_centre" node, because those boundary relations might be the cause of issues in Nominatim if not properly defined.

In fact, in JOSM's history viewer I see that at about the same time this edit was made 3 months ago, Berlin's admin_level=4 boundary relation was restored by re-adding a "boundary=administrative" to the admin_level=4 relation.

Maybe that edit fixed the Nominatim issue as well, and the removal of admin_level=2 on the Berlin place node can be restored?

I sincerely cannot believe the admin_level=2 tag being the issue, as otherwise all other similar tags on Europe's country capitals, would cause issues with Nominatim as well, which they clearly don't (at least, I do not see an attempt by you to remove those as well due to similar issues).

Marco