Suhlasim, ked uz je tam amenity=animal_breeding, tak budova aj takyto opisny nazov je nepotrebny. A preco je rozsah toho chovu zvierat mensi ako je plot okolo? A preco je ten plot tak nakrivo, niekolko metrov od miesta kde je na snimkach vidiet plot (aj ked teda na ESRI to velmi slavne vidiet nie je)? Na snimkach ESRI, ktore pouzivate nie je vidiet ziadnu bytovu vystavbu, takze prinajlepsom by som tam dal landuse=greenfield (pripravene na planovanu vystavbu). A znamena to, ze pouzivate v skutocnosti iny zdroj dat, takze ho prosim uvadzajte. Dakujem

Zdravim, prosim piste zmysluplnejsie komentare sad zmien: osm.wiki/Cs:Dobr%C3%A9_koment%C3%A1%C5%99e_sad_zm%C4%9Bn . 100 sad zmien s popisom "Jasenska dolina" nikomu nic nepovie. Dakujem

There is no problem with the tagging (albeit you should have added garden:type=residential), but that you made it a single village-wide area, thus also under buildings. That is wrong. So please mark individual plots, or at least the areas in the yards in the back of the houses. But there is no garden where the streets run.

Here is the new junction: https://nrenner.github.io/achavi/?changeset=93242025 . Yes, if one wants to detail it this precisely, then you need to split many segments to write correct lanes and turn lanes. And even update bus lines (relations) that went over the old roads. The iD editor isn't very good at dealing with relations and even actively destroys bus relations when the user touches one.

I can do that crossing more precisely if you want:) But where is there a speed bump?
3 separate crossroads are fine, if they are not on the same route. Car going into any direction will only cross one pedestrian crossing, if done correcly. Traffic lights for pedestrians get much higher penalty in OsmAnd than a crossing without lights, which is correct. Anyway, if there are lights, you have to map them, not think about any particular app (like OsmAnd), whether it cares about it or not. Some other app might. So always tag what is correct and on the site.

I meant way/204483245/history . There is only a single lane motorway_link so there is nothing to merge to. It joins with 1 lane from Viedenska cesta, which is 1 lane too. Only after the join, the right of the lanes merges to the left one at way/204483250. The merging lane was already mapped there. So I don't think anything needed to be added to way/204483245/. Bratska joining to motorway D2 seems OK, there is no place as what you have done here.

The wiki is written correctly, there are sometimes multiple ways to do something. embankment=yes on a way is the easy way if there is a single road on top of the embankment. Then adding separate man_made=embankment ways would not add more info and would just be tedious. In the case here adding the ways can be useful, I can do it, thanks.

If you are able to read OsmAnd sources, you should be more than capable to use JOSM :) It works in Java so basically also does not need an install. It has much better tools and data checks (but does not do questionable "upgrades" automatically). I always recommend it. Thanks.

OK, so OSM was correct in details before your change. Great if OsmAnd has a bug report for this and will access to POI even when marked as 'customer access'. But if you saw the OsmAnd routing rules, it will not be easy to solve. Until then, there is the workaround I described. Changing OSM data is not the solution.

But that is no reason to use wrong tags. That is not allowed in OSM to use wrong tags just to make an editor happy or achieve some nice rendering . The object would be semantically wrong and be wrongly interpreted by apps (like OsmAnd). You should always be able to type the right tab manually (for the vaccuum cleaner), if you know what tag you need.

There is some difference between cobblestone (more round) and sett (more square, see surface=* . Please use the values properly.

You added the bump on the footway=crossing way, not on the node shared with road and footway. Sometime you do it right, sometimes not.

I do not see any improvement in tagging or geometry between mine (deleted) and your new way: https://nrenner.github.io/achavi/?changeset=91188860
Ok, let's assume it was a random occurrence.

It did hurt, as there were then 2 objects for the same platform, one with name, one without. Please stop with these "upgrades" of ID editor, they are known to be wrong.

Yes, but "traffic_lights" is not equivalent to "marked"... So are there lights or not?

Hi, please do not randomly change crossing=uncontrolled to crossing=marked. It is a duplicate tag needlessly invented by iD editor and adds no information. So the change is useless.

What is surface=stone on way/854065552? Did you mean paving_stones or sett? See surface=*

Again, why changing crossing=traffic_signals into crossing=marked and losing information of the signals? Also, you can put highway=traffic_signals on the same node as the pedestrian crossing (instead of highway=crossing), then OsmAnd gets less penalty as there will only be one object to pay attention to. When cars have green signal, pedestrians have red ad so cars do not need to slow down. When traffic signals for cars and for pedestrians are separate nodes, apps can't know if they are bound.

If it means that between 18:00 and 07:00 only residents can park there, you could use e.g. "access:conditional=private @ (18:00-07:00)" .

I don't see why you had to delete my crossing at way/235117388, when you then just added it again :(