tyr_asd's Comments
| Changeset | When | Comment |
|---|---|---|
| 129891660 | Hey! I'm sorry for the inconvenience, but there is just no "optimal" approach in such cases: on the one hand, I agree that one should avoid unnecessary global changesets, but in this case I wanted to group these changes together in a single changeset, because they do actually belong together: they all fix the same issue caused by an oversight in iD's tagging presets. I hope you can understand my reasoning. Happy mapping! |
|
| 126142340 | @Audrey101: I'm the developer of the software you used in this map edit (the so called "iD editor"). I believe your change of the "Bahamas" border was not intentional. In order to prevent similar accidents in the future, it would help me a lot if you give us some details of how you started your edit session. I know it has been a few days, but every detail you remember might be important to track the issue down. For example: Did you use the "Search features" utility, especially the "Search worldwide..." option? Did you maybe click on the "Feature Type" of the "Administrative Boundary" to select a feature type for it? Etc. Your help would be very much appreciated! |
|
| 125774774 | Hey. Yeah… I was wondering the same to be honest, but ended up just mapping the routes from the timetable because it seemed like the "easiest" solution. At first, I thought about splitting it at NOI (as some buses do actually end there), but that would leave the false impression that one would need to make a transfer for some direct connections (like CityClinic -> Kaltern). Making the route a roundtrip would mostly work, having only the small downside that it doesn't allow to properly map the origin/destination (from/to) of the individual buses… But maybe that's not super important, is it?! |
|
| 83046518 | Habe jetzt den Verlauf an dieser Stelle (von ca. Plosescharte bis Lüsner Scharte) korrigiert. Die Grenze scheint aber auch darüber hinaus etwas ungenau zu sein. Möglicherweise ist das "Problem" auch nicht nur auf Brixen beschränkt. Man könnte sich vielleicht einmal Gedanken machen die Gemeindegrenzen in ST systematisch zu kontrollieren und ggf. anzupassen. |
|
| 121700743 | ||
| 83046518 | Ja das mit "Version 1" bei "nicht wirklich neuen" Ways ist ein Artefakt, wenn man in einem Changeset einen Weg teilt: dann behält einer der Teile die alte Id (mit Version > 1) und der rest eine neue (mit Version 1). Ich denke mal diese Gebäude hat hier schlicht einfach noch niemand genau gemappt. Ok, ich frage mal bei der Gemeinde nach und korrigiere den Verlauf bei Bedarf. |
|
| 83046518 | Hallo. Du meinst den Verlauf der Gemeindegrenze bei way/787613793, oder? Dieser stammt ursprünglich von diesen changesets: changeset/558435 und
|
|
| 117743587 | Hey. I have noticed that the mopdifications in this changeset have resulted in a small "spike" of the boundary of Russia at the following nodes: node/7770263964, node/7770298536 and node/266012296. Was this intentional? Also, the boundary of Estonia doesn't match the indicated source anymore: compare https://www.riigiteataja.ee/aktilisa/0000/0002/4407/Lisa%202.pdf with node/266012308/history for example. PS: Do you have a link to a digital copy of the source you used in this changeset? |
|
| 115442742 | honestly, it was quite hard to do with JOSM as well: a) it requires a detailed knowledge of the "multipolygon" data structure, and b) rearranging the multipolygon relation members is a tedious process with such large polygons, especially at the locations where inner members become outer borders of the result(s). It would be really nice to have a proper tool which allows to automatically split any polygon in OSM with ease. Ssomething like what [JOSM's utilsplugin2 Alt+X](osm.wiki/JOSM/Plugins/utilsplugin2#Split_area_.28Alt.2BX.29), but also works for multipolygons would be my dream ^^. |
|
| 115442742 | yeah, this one really should be split into significantly smaller chunks. For a start, I shaved this part off: relation/13607045 |
|
| 113488288 | also changeset/104133394 |
|
| 113488288 | Hi! Die Hausnummer stehen so an den Eingängen der Gebäude. Bzgl building=terrace solltest du dich besser an den Mapper wenden der das ursprünglich so gekappt hatte. ;-) |
|
| 112007993 | Merci! Then it looks like it's properly mapped now, except for the additional information (benches, tactile paving, etc.) of course. Happy mapping! |
|
| 112007993 | Hey Fox! Just wanted to let you know that you (accidentally) deleted a part of the B83 here. I have undone the changes to restore the road in changeset/112365517. Could you double-check that the bus stop is now properly placed at the following locations: node/331613474 and node/420866420. Or is that still not fully correct? |
|
| 111111111 | :) |
|
| 107816796 | Hey, ich glaube du hast hier einige kurze Stücke der B252 übersehen (bei way/360065178) wo noch "highway=construction" oder "access:conditional" gesetzt war. Das habe ich jetzt mit changeset/108034564 korrigiert. Vielleicht kannst du nochmal drüber schauen ob jetzt alles passt? Gruß, Martin |
|
| 49972516 | OK, danke für die Antwort. Ich war mir jetzt spontan nicht sicher ob man für diese Art von Materialseilbahnende das Tag aerialway=station benutzen sollte (siehe z.B. die Beschreibung und Bilder in osm.wiki/DE:Tag:aerialway%3Dstation), andererseits wüsste ich jetzt auch keine bessere Alternative dafür und auf der "aerialway=goods" wiki-Seite wird das Tag auch empfohlen: osm.wiki/DE:Tag:aerialway%3Dgoods#Weitere_Eigenschaften. Also sollte es schon so passen. LG! |
|
| 49972516 | Hallo. Ich kann beim besten Willen auf den Luftbildern hier keine Liftstation bei node/4946174662/ erkennen. Ist dort vielleicht eine (sehr) kleine Materialseilbahn, wenn ja wohin führt diese? |
|
| 62329529 | FYI: note/2152437 |
|
| 43604433 | Hi! Könnte/sollte man den "ugs Name" nicht besser als `loc_name` taggen? ;-) |