OpenStreetMap logo OpenStreetMap

Changeset When Comment
175157321

Hello.
You have placed the barriers directly on the SS301 second-class road. I don't know the exact situation on site, but shouldn't the barrier be somewhere on the old abandoned road? The barriers prevent planning along the SS301 second-class road at our Mapy.com. If the road is passable, can you move these two barriers a little to the side onto the old road?
Thank you,
Petr

153766249

Hello.
You have deleted several ways and nodes in this area. May I ask why? It seems very unlikely that paths have been removed in this location.
If this is an error, can you please revert this changeset back?

124671704

Hi. This change goes against this rules:
osm.wiki/One_feature,_one_OSM_element
You shouldn't add second element with same tags just for sake of rendering in OsmAnd. In other apps it makes dupliticies.
Solution is to improve rendering in OsmAnd. I'm removing this node.

134072975

I agree and I've changed tagging to desert=erg.
Have a nice day.

134072975

Hello.
Desert=yes is not a useless tag. It is the only one of the other tags that refers to the Taklamakan Desert as a desert (a geographical term).
The tag natural=sand denotes an area covered by loose sand with no, or almost no, vegetation. However, this may not be a desert and is often used in other cases as well.
I have returned the tag desert=yes.

112158087

I didn't know that relations with natural=sand cannot have inner members. It does not make sense for me. But current state is better for me then previous one. Thanks a lot.

112158087

Hi.
For me is more important to have good data then good looking openstreetmap-carto style. Mapping for rendering is in my opinion not right.
On the other hand "natural=sand" is widledly used and lot of people is using this style.
I'm thinking that way around could be polygon with tag natural=sand and relaiton with one member (this polygon) with tags natural=desert, surface=sand desert=erg, wikidata and wikipedia. Name of desert should be in this case also part of relation, but than it wouldn't be rendered.

112158087

Hi.
OK. It is locally used like this and that is big argument.
But I still miss information about desert in tags. So I'm thinking about adding new tag desert=erg. It is ok for you?

81682394

Na změny uživatele Mamutinka co se týče nemocnic se podívám. Ale chtěl bych upozornit, že si stojíme za tím, že doplnit nemocnice tam, kde chybí, a to na základě veřejně dostupných zdrojů - například webových stránek samotných nemocnic - nepovažujeme za chybu. Je to podle nás hodnotný příspěvek do OSM.

81682394

Co se týče druhé poznámky, tak zde už nedokážu přesně zjistit, na co reagovat. Bod už v mapě není. Nemůžu než souhlasit, že plocha pro klášter je lepší než bod, pokud je nemocnice značená samostatnou plochou. Ale zpětně už posloupnost toho, jak změny v mapě vznikly, dohledat nedokážu.

81682394

Dobrý den.
Současné značení mi přijde víceméně správně. Situaci jsme řešili před rokem a co si vybavuji, tak to, že se zde nachází nemocnice, nebylo v mapě nijak značeno.
To, jestli by v tagu building mělo být hospital nebo monastery, je asi otázkou názoru. Mně přijde, že je lepší mít v tagu building současnou funkci budovy(tedy hospital) a v tagu historic mít uvedený původní funkci budovy(tedy monastery). Ale uznávám, že se na to někdo může dívat jinak.

97052320

Hi. You've added relation of Narciarska trasa biegu Pabla. According to the name, it looks like this is a route for nordic(cross-country) skiing. In that case, "piste:type=nordic" would be better. What do you think about it?

88551315

Hi. You've changed highway=path to highway=cycleway in this area. I think that originaly it was better tagged. Highway=path more corresponds to the nature of paths - they are narrow with ground surface. Access was is clear from foot=no. What is reason behind this change?

92716577

Hi.
Relation relation/5687071 represents administrative region Brittany.
New relation I've made relation/11771931 represents geographical unit - peninsula. Those two entities are not identical. Significant part of administrative region Brittany is inland.

92172231

@aceman444 Souhlasím, že duplicita je mezi těmito dvěma entitami:
node/26037632
way/289862512
Jak jste správně napsal, tag place se stejným name je zde duplicitně.
Ale souhlasím i s @PavelPS, že by bylo lepší polochu 289862512 odstranit. Pokud si mám vybrat mezi označením města plochou a bodem, tak mi přijde lepší bod. Může být umístěn v "přirozeném" centru města. Argument, že plocha lépe vystihne zastavěné území mi nepřijde správný, protože zastavěné území by mělo být značeno pomocí tagů landuse. Také mi nepřijde, že se součástí města jsou jen zastavěné plochy, ale můžou do něj patřit i přilehlé nebo vnitřní nezastavěné plochy. Tím pádem se při použití plochy uchylujeme k subjektivnímu označení hranice, což je sporný přístup.
Použití této relace relation/2204009,
kde je administrativní hranice a bod pro place=city použitý jako admin_center mi přijde ideální. Nevidím v něm žádnou slabinu.
Pokud souhlasíte, můžu tuto duplicitu upravit.

73824532

Hello. Honestly, I don't remember anymore. At this point, it occurs to me that this tag is redundant. I'll delete it.

71107896

OK, so I'll do that. Thank you for cooperation.

71107896

Hi.
In my point of view this approach is not right. It's something like tagging for rendering..
It is also described here:
osm.wiki/One_feature,_one_OSM_element
I
I'm developing this site:
https://en.mapy.cz/s/hegepafufo
I don't think that we shouldn't think of those apps which can't interpret relations, but making duplicities is also not okay. Maybe we can think of how to make it OK for all?

71107896

Hi.
In this changeset you added tags from relation relation/2388678 to polygon way/125668910.
Woudn't be better to leave polygon without any tags or just with tags leisure=park?
Like this it is a duplicity. It makes us trouble.

83115984

Hi. You changed wikidata and wikipedia of relation #449220 which represents state of Taiwan (Republic of China). But wikidata Q22502 represents island Taiwan.
This wikidata is correctly here: relation/7219605.
Can you change it back please?