johantiden's Comments
| Changeset | When | Comment |
|---|---|---|
| 95883227 | ||
| 95883227 | Fixed in
|
|
| 95879748 | I interpret the source (without namespaces) to mean all tags. When I added the community_centre tag, I didn't base that on survey but on common sense. For me it was easier to remove the tag and let future users look at the history instead if they need to know. |
|
| 86093923 | Jag ser det här som en liten förändring. Ändringen är baserad på vad som redan fanns i databasen med tillägg som är rätt så hanterbara. Om datat innan min ändring var fel, så är det fortfarande fel - varken bättreneller sämre. Om datat var rätt innan så är det rätt nu (förutom några misstag). Jag tycker inte att man behöver kolla upp verkligen för varje edit. Sen har jag gjort några fel, som ni upptäckt. Jag kan gå igenom alla Equinor och ta bort brand där, om det verkar rimligt. |
|
| 95315956 | Fyi amenity=disused is deprecated on the wiki. It's encouraged to use disused:amenity=restaurant instead. |
|
| 95317201 | Also, I added this relation in the first place and when it was flagged by Osmose, I felt responsible to clean up my own mess, kind of. |
|
| 95317201 | I see two issues with your reasoning. Firstly, consumer applications can prune away useless data, meaning if we hypotethically cleaned up all of the extra 1-polygon relations in the world, there would be a lot less data to download and parse. So there is some value to cleaning. If we that too much data is a problem for the database I think the solution to this is to manage/clean database history better or discourage users from adding features to the map which is a slippery slope. All edits must be encouraged :) Secondly, you can't really know the future use case for the data. You say that someone might want to add a hole in the center of the multipolygon. Sure, that's a possible future. So is the case that someone wanting to add the forest to another relation, maybe a site or even larger multipolygon. Then they would first have to _remove_ the current multipolygon (like I just did) and then do what they want. Might not be as feasible but I hope you see my point. We can't really prepare because we don't know. |
|
| 95317201 | It's overly complex so I simplified it. If someone needs a multipolygon in the future they can just add it back. |
|
| 83080684 | way/150032713/history#map=19/59.39312/17.00516 This building seems to still be there on aerial images. Are you sure it's gone? |
|
| 93663580 | Cool! It's weird when even the tools have different opinions on how things should be mapped. Osmose flags this as a building intersection. |
|
| 93663580 | Buildings shouldn't be inside other buildings. That's why the parking is tagged as building:part instead of building. If you want to tag it as a building, you should change the area of the adjacent building (with address 2) to not also cover the parking. |
|
| 93070733 | Maybe this is a footway? Did you forget to tag? |
|
| 93070733 | ||
| 90378782 | Orphan provides_feature!
|
|
| 88167589 | If Återvallsvägen 2-4 has been demolished, maybe just remove the buildings altogether? |
|
| 88173900 | Snyggt! Glöm inte att tagga cirkulationsplatser med junction=roundabout så att navigering funkar bättre! Se t. ex. way/827602349 |
|
| 86552869 | Maybe just remove the node? |
|
| 60934923 | Maybe we should just remove these. Its just confusing and there is no reference to any source for the proposal. |
|
| 88636866 | Hi! Nice job on mapping so many details! One thing though: When mapping parking surface, make sure that the road leading to them cuts through the area so that routing softwares can properly find the way to them. It's better to make the parking area too large, overlapping onto the road (since this is the way any vehicle would enter/exit the parking anyway. |
|
| 87467225 | You can use this (hard-to-use) tool to edit advanced opening hours. Some examples at the bottom.
|