michikommader's Comments
| Changeset | When | Comment |
|---|---|---|
| 179747050 | Stopp, ich muss zurückrudern. Ich bin gerade auf dem DLR-Gelände an Gebäude 130 vorbeigelaufen und dort klebt tatsächlich eine Hausnummer "6" neben dem Eingang! Das ist verwirrend. An der Pförtnerei wurde mir hingegen bestätigt, dass auf dem DLR-Gelände alles über die 7 läuft.
|
|
| 178957779 | @Hb-, ich habe die DLR-eigenen Gebäudenummern jetzt alle von addr:housenumber zu addr:unit geändert. Der OSM Inspektor scheint jetzt keine Fehler mehr zu werfen, aber ist ein alleinstehendes addr:unit valide, ohne die anderen addr:*-Tags wie addr:street? Oder wird OsmAnd weiterhin Probleme haben? |
|
| 179747050 | Top! Ja, 7 macht Sinn. Das Gebäude gehört nun aber schon ziemlich lange zum DLR-Gelände an der Adresse 7. Interessant, dass das LGLN in den ALKIS-Daten da noch ne 6 führt. |
|
| 179747050 | Hausnummer von way way/34720447 müsste eigentlich 7 sein und nicht 6 oder 9, denn Gebäude 130 gehört zum DLR-Gelände, welches offiziell an Lilienthalplatz 7 beheimatet ist. Oder wo hast du deine Info her? :-) |
|
| 178957779 | Meine Intention dahinter, addr:housenumber zuzuweisen, war, dass bspw. Mapy (https://mapy.com/de/turisticka?l=0&source=osm&id=1191345276&x=10.5622991&y=52.3150148&z=18) dann die DLR-internen Gebäudenummern als "Hausnummern" rendert, was praktisch ist. Zumindest hatte ich es bei ein oder zwei Gebäuden zufällig bemerkt und mich gewundert, warum die Nummern bei den anderen nicht gerendert werden, und anschließend diesen Tag bei den anderen befüllt. Aber ja, das ist natürlich dann nur eine mögliche Interpretation auf Mapy-Anwendungsseite und offensichtlich nicht zielführend, da fehlerverursachend. |
|
| 178957779 | Nee, ich nutze OsmAnd nicht. |
|
| 178957779 | Alles klar, danke für den Hinweis! Ich schaue mir das im Detail die kommenden Tage mal an und werde es reverten bzw. zielführend umbauen. |
|
| 134988730 | I understand the use case of distinguishing between different thematic layers from GIS perspective. But, due to the data model of OSM, the only possibility of type distinction of polygons is through their attributes, isn't it? A GIS application will always have to apply a filter on these attributes in order to separate polygonal features into separate thematic "layers". An then it should not make a difference if one polygon describes two different types, or, if two geometrically similar polygons describe one type each. Though, I see a disadvantage of the latter variant, where housekeeping of (nearly) duplicate geometries, in order to hard-codedly separate the attributive meaning, can lead to an overhead from data/geometry maintenance perspective. If both polygons significantly differed in their geometrical shape, I would for sure see it valid to model them as separate geometries. But in this very case I carefully compared the data and, also with local knowledge of having been there, came to the conclusion that my change would be beneficial when trying to avoid data duplication. Also, as far as I remember, my result rendered more conveniently in OSM-based mobile mapping apps. I am open for more thoughts from your side. I will also re-evaluate my change and can revert it if it breaks conventions or poses other problems which I have not
|