Re: [Talk-de] Totenbretter
Im Forum wurde das Thema schon mal kurz angeschnitten, dort gibt es einen Thread der sich speziell mit historischen Objekten befasst: http://forum.openstreetmap.org/viewtopic.php?pid=473183#p473183 Am 4. April 2015 um 00:00 schrieb Helmut Kauer li...@helmut-kauer.de: Griaß eich, in Bayern gibt es den Brauch der Totenbretter. Im weitesten Sinne könnte man sie als Andachtstätten bezeichnen. https://de.wikipedia.org/wiki/Totenbrett Dort wo ein Wegkreuz dabei ist, kann man ja klar Andachtsstätte mappen. Was an den anderen Plätzen? Gruß Helmut -- Helmut Kauer Bodelschwinghstraße 35 83301 Traunreut ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Honga Tonga eintragen, Bildquelle?
Zur Ergänzung: In OSM hat jemand die neue Küstenlinie bereits vor 7 Tagen eingezeichnet. Ohne Quellenangabe. http://www.openstreetmap.org/way/325720273 Am 7. Februar 2015 um 00:57 schrieb Christoph Hormann chris_horm...@gmx.de : On Friday 30 January 2015, Christoph Hormann wrote: [...] In diesem Fall besteht aber nicht wirklich so große Notwendigkeit - in ein paar Wochen gibt es aus den üblichen Quellen, insbesondere Landsat, die ersten rechtlich einwandfreien Quellen, die eine grobe Erfassung ermöglichen würden. Der Vollständigkeit halber: gibt jetzt ein erstes weitgehend wolkenfreies EO1-Bild, was die neue Insel nicht komplett aber größtenteils enthält: http://earthexplorer.usgs.gov/metadata/1852/EO1A0700742015035110KF_PF2_01/ http://www.imagico.de/files/EO1A0700742015035110KF_rgb8.tif -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Honga Tonga eintragen, Bildquelle?
Am 30. Januar 2015 um 11:16 schrieb Christoph Hormann chris_horm...@gmx.de : Und extreme Präzision in der Erfassung ist bei einem so jungen Gebilde sowieso nicht sonderlich nützlich und die aktuelle Erfassung der Küstenlinien der Inseln ist auch nicht deutlich besser. +1 Auf Bildern von 2009 ist südlich der Insel ein Vulkankrater sichtbar, der mittlerweile wieder verschwunden ist, wenn man die Airbus-Bilder mit denen der NASA vergleicht: http://eoimages.gsfc.nasa.gov/images/imagerecords/37000/37657/tonga_ast_2009084_lrg.jpg Der 2009er Krater wurde in OSM vor 7 Tagen eingetragen: http://www.openstreetmap.org/way/323780484 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Request for feedback: new building colours in openstreetmap-carto
Hi, it seems to me that the demo server doesn't work? Neither with the actual Chrome or Firefox. Regards, Archer 2014-11-27 2:16 GMT+01:00 Matthijs Melissen i...@matthijsmelissen.nl: Dear all, We are considering to change the colour of buildings in openstreetmap-carto, the default rendering on openstreetmap.org. Because this change has a significant effect on the looks of the map, we would like to consult the community before going ahead with this change. A rendering demo can be found here (left the current rendering, right the proposal): http://bl.ocks.org/pnorman/raw/c61d6b11193081910866/#15.00/50.0611/19.9393 http://bl.ocks.org/pnorman/raw/c61d6b11193081910866/#14.00/40.7048/-74.0040 Please note that only selected regions have been loaded into the demo server. As can be seen, the new building colour is much lighter. This should make the map more pleasant to the eye, as well as make it easier to see the road network in areas with many buildings. More info can be found in the Github issue: https://github.com/gravitystorm/openstreetmap-carto/pull/565. I would like to thank Paul Norman and Mateusz Konieczny, who have done the majority of the work. Please let us know what you think of the new rendering, either on Github or as a reply to this message. Kind regards, Matthijs ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Request for feedback: new building colours in openstreetmap-carto
Seems to be fixed. Now I can view the demo. 2014-11-27 2:25 GMT+01:00 Archer arc...@gulli.com: Hi, it seems to me that the demo server doesn't work? Neither with the actual Chrome or Firefox. Regards, Archer 2014-11-27 2:16 GMT+01:00 Matthijs Melissen i...@matthijsmelissen.nl: Dear all, We are considering to change the colour of buildings in openstreetmap-carto, the default rendering on openstreetmap.org. Because this change has a significant effect on the looks of the map, we would like to consult the community before going ahead with this change. A rendering demo can be found here (left the current rendering, right the proposal): http://bl.ocks.org/pnorman/raw/c61d6b11193081910866/#15.00/50.0611/19.9393 http://bl.ocks.org/pnorman/raw/c61d6b11193081910866/#14.00/40.7048/-74.0040 Please note that only selected regions have been loaded into the demo server. As can be seen, the new building colour is much lighter. This should make the map more pleasant to the eye, as well as make it easier to see the road network in areas with many buildings. More info can be found in the Github issue: https://github.com/gravitystorm/openstreetmap-carto/pull/565. I would like to thank Paul Norman and Mateusz Konieczny, who have done the majority of the work. Please let us know what you think of the new rendering, either on Github or as a reply to this message. Kind regards, Matthijs ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Gebiete bezeichnen - Meer, Golf, Bucht
Wenn die Verbindungslinie an den Grenzen/Küstenlinien hängt, können bei kleinen Fehlern schnell grössere Struktuen zerstört werden. Das Problem hat man eigentlich immer in OSM. Die gängigen Editoren packen die neuen Wegstücke in die Relation wenn ein Weg aufgespalten wird. In vielen anderen Ländern ist die Küstenlinie teil von Admin-Relationen. So gravierende Probleme gibt es da nicht, das klappt meist recht gut. Wie macht man das technisch: wie lädt man eine so lange Küstenlinie in die neue Relation? Mit JOSM http://josm.openstreetmap.de/ Die Hierarchie sollte auch kein Problem darstellen, die ergibt sich automatisch aus der räumlichen Konfiguration Wie ergibt sich die Hierarchie? Wie unterscheidet man bei natural=bay: - kleine Badebucht - Lübecker Bucht - Golf von Aden - etc. ob eine Bucht klein oder groß ist geht aus der Größe hervor, falls die Fläche in OSM eingetragen ist. Bei Seen wird die Größe z.B. schon berücksichtigt und große Seen werden früher auf der osm.org-Karte angezeigt ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebiete bezeichnen - Archipel, Insel, Inselchen, Fels
_Archipel_ Beim Archipel werden vermutlich oft nur die Hauptinseln in die Relation eingebunden (manche mit vorgelagerten Kleininseln, manche ohne), Und kleinere Insern werden oft vergessen. Eine Bounding-Linie wäre zwar eindeutig, aber das wäre eine virtuelle Marke... Dann muss man halt die fehlenden Inseln in der Relation nachtragen, das ist kein Grund irgend eine Bounding-Box drumrum zu zeichnen um Zeit zu sparen. _Hierarchie_ Zwischen Archipel, Insel und Inselchen zu unterscheiden ist ungenügend. Dominanz und Prominenz sind nicht berücksichtigt: https://de.wikipedia.org/wiki/Dominanz_%28Geographie%29 Zusätzlich berücksichtigen muss man die Bedeutung der Insel: - Fährhafen - Industriehafen - Flughafen - Regierungssitz - Einwohnerzahl - Fäche - etc. Die Bedeutung der Insel kann man mit GIS-Tools berechnen, Flughäfen etc. werden in OSM erfasst. Erster Gedankengang: Man berechnet, wie viele Städte, Dörfer, Flughäfen etc. sich auf der Insel befinden und erhält so die Bedeutung. Man sollte aber dann noch alle Inseln die in einem Archipel liegen miteinander vergleichen, um die lokale Bedeutung festzustellen, man kann nicht eine Insel auf den Marshall-Islands mit Hispaniola vergleichen. Die Dominanz lässt sich auch berechnen. Zu den Tags: Es gibt auch noch natural=shoal für Sandbänke ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebiete bezeichnen
im Forum findet sich dazu was: http://forum.openstreetmap.org/viewtopic.php?id=16094 Gruß Am 25. September 2014 12:50 schrieb Markus liste12a4...@gmx.de: Welche Möglichkeiten gibt es, Gebiete zu bezeichnen? Diese haben ja keine festen Grenzen... und sind oft irgendwie hierarchisch gegliedert... Beispiele: Mittelmeer Adia Kroatische Küste Dalmatien Ostsee Südliche Ostsee Kieler Bucht Kieler Förde Alpen Zentralapen Walliser Alpen Matterhorn Vielleicht gibt es da schon Lösungen oder Lösungsideen (oder wir wissen zumindest wie es nicht geht) aus den Bereichen Gebirge und Landschaften? Mit herzlichem Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unbenutzbare Wanderwege - was tun?
Am 24. September 2014 22:04 schrieb thsMD thomas.schind...@ovgu.de: Hi, ich mache gerade Urlaub in den Alpen. Dabei ist mit aufgefallen, dass in der OSM-Karte Bergwanderwege T3/T4 vorhanden sind, die nicht mehr benutzbar sind. Keine Wegweiser an den Kreuzungen/Einmündungen oder Kreuzungen/Einmündungen nicht gar nicht meht vorhanden. Verlauf kann man stellenweise noch erahnen, aber Weg ist wie gesagt garantiert nicht benutzbar. Weg benutzbar oder nicht ist ein eher subjektives Kriterium. Für andere Abenteurer wird es da möglicherweise erst interessant. Für schlecht sichtbare Wege gibt es den Tag trail_visibility=horrible bzw. no siehe: http://wiki.openstreetmap.org/wiki/DE:Key:trail_visibility ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] 112k Wikidata tags to add to OSM
https://wdq.wmflabs.org/ is a powerful Tool for Wikidata I used the Wikipedia categories because the Wikidata 'instance of' property is often missing. I'm struggling to figure out how to use the Wikidata API to search for items by 'instance of' property. You're right I should add 'instance of' claims to Wikidata items. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 112k Wikidata tags to add to OSM
There is a difference between municipality and settlements like villages. Wikipedia articles are often about the whole municipality and not about a single village. So the wikidata-tag should only be tagged onto the administrative relation for the municipality Please do not add any Wikidata-Tags to German villages/municipality. This would cause a big mess as the mismatch list shows. I'd oppose this import at all at the moment. There are currently 21533 objects with wikidata tags in the OSM database at the moment. Your algorithm produces 2393 mismatches. This is a error rate of 10 % !! I think it's better to have not so much wikidata-tags in our database than about 11000 wrong tags. 2014-09-05 11:06 GMT+02:00 Edward Betts edw...@4angle.com: I modified my code, adding more categories and extending the matching distance for some objects. I started checking addr:housename, some buildings have this tag but are missing the name tag. http://edwardbetts.com/osm-wikidata/ There are now 112,278 matches found. I thought the extended range would help reduce the number of mismatches, but I now have 2,393 mismatches. http://edwardbetts.com/osm-wikidata/mismatches.html I've got some ideas about how to fix some of the mismatches. Many of the mismatches are villages represented by both a node and a relation, but the relation isn't tagged with place=village, so my code can't tell it represents the same thing. Maybe relations that represent villages should be tagged with place=village. I'll could modify my code so it rejects nodes inside a way or relation with the same name. Example: Sachsendorf, Germany http://www.openstreetmap.org/node/240130457 http://www.openstreetmap.org/relation/2253462 -- Edward. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 112k Wikidata tags to add to OSM
:Stonehenge: https://www.wikidata.org/wiki/Q39671 https://www.wikidata.org/wiki/Q587584 both WD objects match the same OSM object: http://www.openstreetmap.org/way/37118074 Berlin Wall: http://wikidata.org/wiki/Q5086 matches only one way of the wall but the Wiki article says there are three parts of the wall and different watchtowers left. Maybe those objects should get each their own Wikidata-object. Yosemite National Park http://wikidata.org/wiki/Q180402 (Q180402) node Yosemite http://www.openstreetmap.org/node/408906523 should match the national park nothing spectacular yet. the main matching problems are villages, other settlements and administrative divisions as Wikipedia doesn't distinguish here. In Wikidata you have to distinguish to get a correct ontology. district -- municipality -- settlements. Much consolidation has to be done in Wikidata yet. - suburbs: Whitchurch, Bristol http://wikidata.org/wiki/Q7994194 (Q7994194) node Whitchurch http://www.openstreetmap.org/node/29674271 maybe should match the relation http://www.openstreetmap.org/relation/2944649 unclear, WP article says village but the map shows the city council ward Pihlajisto http://wikidata.org/wiki/Q3069705 (Q3069705) node Pihlajisto http://www.openstreetmap.org/node/206335421 maybe should match the relation http://www.openstreetmap.org/relation/190373 like the map in WP shows Ringwood East http://wikidata.org/wiki/Q7335020 (Q7335020) node Ringwood East http://www.openstreetmap.org/node/2592650968 maybe should match http://www.openstreetmap.org/relation/2401669 + more examples if needed - villages Cerhonice http://wikidata.org/wiki/Q2140210 (Q2140210) node Cerhonice http://www.openstreetmap.org/node/1599176850 maybe should match http://www.openstreetmap.org/relation/437515 Wikipedia says is a village and municipality. The village and the municipality have different areas and therefore should be split into different objects in Wikidata + mismatch list +++ - towns: Hilpoltstein http://wikidata.org/wiki/Q521132 (Q521132) Hilpoltstein http://www.openstreetmap.org/node/240112461 (node) should match the relation for the municipality Hilpoltstein and not the town: http://www.openstreetmap.org/node/240112461 For the town a different object has to be created in Wikidata. Pocking http://wikidata.org/wiki/Q279629 (Q279629) Pocking http://www.openstreetmap.org/node/63655606 (node) same case as Hilpoltstein, should match the following relation: http://www.openstreetmap.org/relation/958087 + many more examples if needed Lagoa http://wikidata.org/wiki/Q2652722 (Q2652722) node Lagoa http://www.openstreetmap.org/node/25277559 Lagoa Municipality http://wikidata.org/wiki/Q985519 (Q985519) node Lagoa http://www.openstreetmap.org/node/25277559 2014-09-05 11:06 GMT+02:00 Edward Betts edw...@4angle.com: I modified my code, adding more categories and extending the matching distance for some objects. I started checking addr:housename, some buildings have this tag but are missing the name tag. http://edwardbetts.com/osm-wikidata/ There are now 112,278 matches found. I thought the extended range would help reduce the number of mismatches, but I now have 2,393 mismatches. http://edwardbetts.com/osm-wikidata/mismatches.html I've got some ideas about how to fix some of the mismatches. Many of the mismatches are villages represented by both a node and a relation, but the relation isn't tagged with place=village, so my code can't tell it represents the same thing. Maybe relations that represent villages should be tagged with place=village. I'll could modify my code so it rejects nodes inside a way or relation with the same name. Example: Sachsendorf, Germany http://www.openstreetmap.org/node/240130457 http://www.openstreetmap.org/relation/2253462 -- Edward. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] addr:state massen remove in DE
Macht man durch einen Revert nicht noch mehr kaputt? - Immerhin wurden 17977 Wege und 25460 Nodes über ganz Deutschland verteilt geändert, da dürfte es unendlich viele Bearbeitungskonflikte geben mittlerweile... Ich wollte gerade ausprobieren wieviele Konflikte JOSM ausspuckt, leider ist es beim Laden des Changesets abgestürzt. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Adding Wikidata tags to 70k items automatically
Please don’t understand me wrong. I’m a big fan of Wikidata but I'm against an automated import. The mismatches list gives good examples that your matching algorithm doesn't work very well: http://edwardbetts.com/osm-wikidata/mismatches.html Some examples: 1. Isar Nuclear Power Plant http://wikidata.org/wiki/Q569510: your algorithm matches only one reactor of the power plant: Isar 2 http://www.openstreetmap.org/way/32918120 but the right matching would be Kernkraftwerke Isar http://www.openstreetmap.org/way/23802422 2. Heligoland http://wikidata.org/wiki/Q3038: you’ve matched the island Heligoland http://www.openstreetmap.org/relation/3787052 but the right match would be the municipality Heligoland http://www.openstreetmap.org/relation/1157962 (for the island there exists a different object in Wikidata) 3. Puerto Rico http://wikidata.org/wiki/Q1183: the Wikidata objects says „is a unincorporated area of the United states“ – the right match therefore would be the administrative relation: Puerto Rico http://www.openstreetmap.org/relation/306157 but your algorithm matches the island: Island of Puerto Rico http://www.openstreetmap.org/node/357271412 I also don’t understand why you prefer nodes instead of ways or relations. Ways and relations provide more information (e.g. extent of an area) than nodes. The Matching algorithm should first look for relations, when there’s no relation it should search for ways. Nodes should come last. What does your matching algorithm when a Wikidata object describes different objects and therefore should be split? A good example for this is the Wikidata object for Thasos https://www.wikidata.org/wiki/Q204096 (currently it describes the island and the municipality “Thasos”) but the object has to be split into two Wikidata objects so that you can say “the island Thasos lies in the administrative division Thasos”. There are also other examples like mixed up nature reserves, lakes and administrative divisions in Wikidata which you have to solve before you can import the IDs into OSM. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Adding Wikidata tags to 70k items automatically
2014-08-31 20:19 GMT+02:00 Edward Betts edw...@4angle.com: Archer arc...@gulli.com wrote: Please don’t understand me wrong. I’m a big fan of Wikidata but I'm against an automated import. The mismatches list gives good examples that your matching algorithm doesn't work very well: http://edwardbetts.com/osm-wikidata/mismatches.html Some examples: 1. Isar Nuclear Power Plant http://wikidata.org/wiki/Q569510: your algorithm matches only one reactor of the power plant: Isar 2 http://www.openstreetmap.org/way/32918120 but the right matching would be Kernkraftwerke Isar http://www.openstreetmap.org/way/23802422 Q569510 is matching Isar 2 (Way 32918120) because Isar 2 is in the list of German aliases in the Wikidata object: [ KKW Isar, AKW Isar, Isar 2, Kernkraftwerk Isar I, Isar 1, Atomkraftwerk Isar ] The German label on the Wikidata item is Kernkraftwerke Isar, notice the extra 'e' on the end of the first word. I could add Levenshtein distance calculations to my matching, we could say if there is a single character difference the names match. With this change both OSM objects would match and my code would skip the wikidata item. The problem with this change is that hill and hall would match. Ok, but the Wikidata object describes the whole power plant and not only one reactor. I'd propose to take is a (WD-Property: P37) into account. For example in Wikidata Q569510 is classified as a nuclear power plant (Q134447) the match algorithm should find the matching OSM tags. For example for power plants the right tag would be power=plant. Otherwise there should be no match. 2. Heligoland http://wikidata.org/wiki/Q3038: you’ve matched the island Heligoland http://www.openstreetmap.org/relation/3787052 but the right match would be the municipality Heligoland http://www.openstreetmap.org/relation/1157962 (for the island there exists a different object in Wikidata) I can't find the Wikidata item that represents the island. island: https://www.wikidata.org/wiki/Q3129772 municipality: https://www.wikidata.org/wiki/Q3038 archipelago: https://www.wikidata.org/wiki/Q17515918 I also don’t understand why you prefer nodes instead of ways or relations. Ways and relations provide more information (e.g. extent of an area) than nodes. The Matching algorithm should first look for relations, when there’s no relation it should search for ways. Nodes should come last. The matching algorithm is only considering objects within 400m, so the nodes happen to be close, but the centre of the relation is more than 400m from the location in Wikidata. I've modified my matching algorithm to use much large distances for some types of object, it is running now. My hope is that when it is finished the code will detect the presence of the node and relation and skip the Wikidata item. Most of these node vs relation mismatches should disappear. The radius for natural and administrative features should be much bigger. For example if you want to find the island Hispaniola you'll need a radius of 93 km. There are also big glaciers, lakes, etc. What does your matching algorithm when a Wikidata object describes different objects and therefore should be split? A good example for this is the Wikidata object for Thasos https://www.wikidata.org/wiki/Q204096 (currently it describes the island and the municipality “Thasos”) but the object has to be split into two Wikidata objects so that you can say “the island Thasos lies in the administrative division Thasos”. There are also other examples like mixed up nature reserves, lakes and administrative divisions in Wikidata which you have to solve before you can import the IDs into OSM. My code doesn't do anything special with a wikidata item that represents multiple things like islands and municipalities. If Wikidata/Wikipedia claim a thing is an island, and in OSM there is a thing tagged with place=island and the same name they will match. OSM objects can be tagged as both an island and a municipality. I'd propose to drop Wikidata objects which have the following property combinations: is a island and at the same time administrative division is a nature reserve and administrative division is a lake and administrative division is a forest and administrative division These are the combinations where I've encountered problems in Wikidata yet. Another problem here: municipality Langeneß: https://www.wikidata.org/wiki/Q29931 the algorithm matches the island which is also called Langeneß. But the island has its own WD-object: https://www.wikidata.org/wiki/Q13747872 OSM Tags und Wikidata Propertys (P39) should be compared and only if the attributes match there should be a match. Or Mawson Peak: http://www.openstreetmap.org/node/2774722248 the match of the algorithm was Big Ben (volcanoe) https://www.wikidata.org/wiki/Q858516 but it should be Mawson Peak: https://www.wikidata.org/wiki/Q2114101
Re: [OSM-talk] Adding Wikidata tags to 70k items automatically
For the category Villages there seems to be also a matching problem. For example https://www.wikidata.org/wiki/Q1639627 is a municipality according to Wikidata but the match is place=village: http://www.openstreetmap.org/node/897680195 and not the administrative relation for the municipality: http://www.openstreetmap.org/relation/437755 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Adding Wikidata tags to 70k items automatically
I'm not looking at P37 (instance of) because many of the wikidata items don't include it. I depend on the the article categories from English Wikipedia. Ok, I'm not familiar with article categories in the english Wikipedia. This may cause problems as Wikidata contains more objects than Wikipedia and Wikipedia often describes two or more objects in one article. For example the Wikipedia article about the islands Langlütjen describes two different islands: https://en.wikipedia.org/wiki/Langl%C3%BCtjen In Wikidata each island has its own object: https://www.wikidata.org/wiki/Q17130505 and https://www.wikidata.org/wiki/Q17130568 The algorithm matched https://www.wikidata.org/wiki/Q458905 and http://www.openstreetmap.org/way/286346464 Adding instance of to Wikidata would be a perfect challenge for https://tools.wmflabs.org/wikidata-game/# ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Adding Wikidata tags to 70k items automatically
sorry, the right match for Q1639627 would be http://www.openstreetmap.org/relation/433042 I've found some more examples for villages in the Czech Republic (I've looked only randomly) if you need some more please let me know. In your mismatch list there seem to be many german municipalities: http://edwardbetts.com/osm-wikidata/mismatches.html In my opinion this import is to early. Wikidata needs much consolidation atm (many instance of missing, etc). We shouldn't rely on Wikipedia categories for the import of Wikidata IDs. Those categories seem to be problematic as they mix up for example villages and municipalities. There may also be problems when the Wikipedia article describes two or more objects (for example one article for the islands Langlütjen as I mentioned before). 2014-08-31 21:33 GMT+02:00 Archer arc...@gulli.com: For the category Villages there seems to be also a matching problem. For example https://www.wikidata.org/wiki/Q1639627 is a municipality according to Wikidata but the match is place=village: http://www.openstreetmap.org/node/897680195 and not the administrative relation for the municipality: http://www.openstreetmap.org/relation/437755 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-GB] City names translation
Single words have no copyright [1]. If he didn't copy it from any database which is affected by the database right [2] it's ok to add them to OSM. [1] https://en.wikipedia.org/wiki/Copyright#Obtaining_and_enforcing_copyright [2] https://en.wikipedia.org/wiki/Sui_generis_database_right Under what licence was it made available? ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-de] Radweit routen löschen? (WAS: Radweit)
Das Problem von privaten Wander-/Rad- oder sonstigen Freizeitrouten ist, dass sie theoretisch bis ins unendliche skalieren. Ich sehe hier die Befürworter von nicht ausgeschilderten Routen in der Bringschuld, klare Regeln auszuarbeiten und zur Diskussion zu stellen, welche nicht ausgeschilderten Routen in OSM eingetragen werden dürfen. Sonst könnte ja jeder kommen und seine private Route eintragen. Die aktuelle Regelung finde ich eigentlich recht klar und unmissverständlich: http://wiki.openstreetmap.org/wiki/Fahrradroutentagging_Deutschland: Welche Routen sollen erfasst werden? Es sollen Routen erfasst werden, die auch in der Realität existieren. Schlagendes Argument ist ihre Ausschilderung mit einer Wegweisung http://de.wikipedia.org/wiki/Radverkehrsnetzwerk#Fahrradwegweisung entlang der Route. Dadurch erhalten sie einen offiziellen Charakter. Am 8. August 2014 23:58 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Volker Schmidt vosc...@gmail.com wrote: Wenn eine Autoroute als Klein-Hintertupfinger-Spaetlesen-Strasse ausgeschildert ist, kann sie (sollte sie) als Auto-Route in OSM gemappt werden. Wenn Leute weniger Spätzle connection IRL haben und das nicht ausgeschildert kriegen haben sie also Pech gehabt? Sorry, echt das kann nicht sein. Auf [TM] Mist a la GR[TM] hab ich nämlich ebenfalls keinen Bock. Wir führen ein private recommendation oder ähnliches tag ein und gut ist. Sowas kann man allenfalls in ferner Zukunft außerhalb der OSM Datenbank sinnvoll pflegen, wenn man an den Änderungen dranbleiben möchte. Gruss Sven -- Ich fürchte mich nicht vor der Rückkehr der Faschisten in der Maske der Faschisten, sondern vor der Rückkehr der Faschisten in der Maske der Demokraten (Theodor W. Adorno) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Loch im Schwarzwald
Das geht wohl auf den iD-Auswahl-Bug zurück, im Forum gibt es einen Thread dazu: http://forum.openstreetmap.org/viewtopic.php?pid=440385#p440385 Am 6. August 2014 11:08 schrieb Joachim Kast osm...@dd1gj.de: Am 06.08.2014 um 10:50 schrieb Sven Geggus: Moin, mir ist gerade ein etwas merkwürdiges Loch im Schwarzwald aufgefallen: http://www.openstreetmap.org/#map=13/48.5472/8.1334 War das schon mal richtig? Gruss Sven Hallo Sven, am 10.07.2014 haben sich im Raum Achern ein paar Halbstarke ausgetobt. Die Accounts waren: Na2412 FENDT 724 Neymar Ariana Grande-Butera dedenne1 love123456789 Scherox Yddak minecraf Felilein my nigga Da könnte einiges kaputtgegangen sein. Grüße Joachim ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radweit routen löschen? (WAS: Radweit)
Private Routen haben bei OSM nichts verloren. Wenn jemand meint er muss seine Lieblingsstrecken der Öffentlichkeit zur Verfügung stellen dann kann er das auf seiner Homepage machen oder auf Diensten wie http://www.gpsies.com/ Am 5. August 2014 17:58 schrieb Henning Scholland o...@aighes.de: Am 04.08.2014 um 21:50 schrieb Michael Reichert: Kennt ihr Routenabschnitte von Radweit-Routen, an denen Radweit-Aufkleber oder Schilder angebracht sind? Ich würde die nicht ausgeschilderten Routen in den nächsten Wochen löschen, da sie nicht der Wirklichkeit entsprechen. We map what's on the ground! Machst du dann gleich bei highway=proposed und anderen Dingen in OSM weiter, die nicht On the Ground sind? Ansonsten fände ich es sehr schade, wenn die Übereinkunft, dass nur falsches gelöscht wird und der Rest ungetaggt wird außer Kraft gesetzt wird. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wochenaufgabe: Geldautomat - War: Wochennotiz Nr. 208 8.7.–14.7.2014
Wenn man dort nicht tanken/kaufen muss würd ich da einfach ein atm punkt reinsetzen. opening_hours wird IMO zum Beispiel von osmand bei allen pois interpretiert. -1 amentiy=atm ist ganz klar als Geldautomat definiert. Das sollte man nicht verwässern. An automated teller machine (ATM), or automatic banking machine (ABM), or cash machine, is a computerised telecommunications device that provides the clients of a financial institution with access to financial transactions in a public space *without the need for a cashier, human clerk or bank teller.* http://wiki.openstreetmap.org/wiki/Tag:amenity%3Datm Für solche Services sollte man einen eigenen Tag kreieren (vielleicht gibt es ja schon was passendes im Wiki). Ich persönlich fände es äußerst unangenehm an so einer Kasse Geld abheben zu müssen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place-nodes von Großgemeinden wurden gelöscht
Am 20. Juli 2014 01:32 schrieb Andreas Goss andi...@t-online.de: ich denke, dass Großgemeinden keinen place-node bekommen sollten. place=* beschreibt eine Ansiedlung bestimmter Größe. Eine Großgemeinde ist ein administrativer Zusammenschluss mehrerer solcher Ansiedlungen. Das ist dann eine Sache für boundary-Relationen. Mit der Logik müsste man dann auch Bayern usw. rausnehmen http://www.openstreetmap.org/node/473848012 Nein, place=state ist ja definiert für A high-level sub-national political entity. Der Bayern-Node hat also keine falschen Attribute. Redundant ist das ganze natürlich schon. Tirkon scheint es aber wohl eher um Gemeinden zu gehen, die keine entsprechende Siedlung haben, wie z.B. Krummhörn http://www.openstreetmap.org/node/240114463 die aber trotzdem mit place=town in der Pampa getaggt sind. Das ist aber falsch, da place=village/town/city/hamlet nur für Siedlungen benutzt werden soll. http://wiki.openstreetmap.org/wiki/DE:Key:place Ich habe ja schon im Ursprungsposting gesagt, dass ich mich dieser Argumentation nicht entziehe. Wie aber bekommen wir dann die Diskrepanz aus der osm.org Karte, dass der Name von Kleinstgemeinden gerendert wird aber diejenige von Großgemeinden nicht und somit die Orientierung erschwert bis verunmöglicht? Es gibt role=label http://wiki.openstreetmap.org/wiki/Relation:boundary was im Moment aber nicht wirklich unterstützt bzw. wohl nur zusammen mit place nodes? Man bräuchte dann wohl etwas wie place=label oder label=yes Von dem rauslöschen halte ich nichts. Derjenige sollte sich vorher erst einmal um einer alternative Lösung kümmern, zumal es eben das gängige tagging ist. Wenn man den Node erhalten will dann aber bitte richtig taggen mit place=municipality, das stört dann auch keine Auswerter (man stelle sich vor ich frage alle Städte ab mit place=town und bekomme dann auch Großgemeinden etc. ausgegeben). Auf github findet man schon ein issue zum Thema Rendering von boundary=administrative: https://github.com/gravitystorm/openstreetmap-carto/issues/104 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-GB] Adding links to Wikidata (and Wikipedia?)
It's also, for simialr reasons, easier for a human editor to add a Wikipedia link, but a script (or even the editing tool itself) could then do a lookup and subistite, or add, the Wikidata ID. It isn't that easy to add Wikidata ID's with a script. Wikipedia articles often describe more than one object. For example the article of Heligoland: http://en.wikipedia.org/wiki/Heligoland The article describes the island and the municipality. To model this in Wikidata you need two different objects. For the island: https://www.wikidata.org/wiki/Q17043877 and municipality: https://www.wikidata.org/wiki/Q3038 I've tried to describe the issue here: http://wiki.openstreetmap.org/wiki/Key:wikidata Sorry for my bad english. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] Fwd: Adding links to Wikidata (and Wikipedia?)
dito for the list... -- Forwarded message -- From: Archer arc...@gulli.com Date: 2014-06-17 15:21 GMT+02:00 Subject: Re: [Talk-GB] Adding links to Wikidata (and Wikipedia?) To: Andy Mabbett a...@pigsonthewing.org.uk 2014-06-17 14:57 GMT+02:00 Andy Mabbett a...@pigsonthewing.org.uk: On 17 June 2014 13:14, Archer arc...@gulli.com wrote: It isn't that easy to add Wikidata ID's with a script. Wikipedia articles often describe more than one object. For example the article of Heligoland: http://en.wikipedia.org/wiki/Heligoland I don't see why an issue with a Wikipedia article makes it difficult to refer to Wikidata. The article describes the island and the municipality. To model this in Wikidata you need two different objects. For the island: https://www.wikidata.org/wiki/Q17043877 and municipality: https://www.wikidata.org/wiki/Q3038 The former has property instance_of=island The latter has instance_of=municipality_of_Germany OSM relation 3787052 has tag place=island and is, correctly, already tagged wikidata=Q17043877 There is clearly an equivalence between instance_of=island and place=island There is no equivalence between place=island and instance_of=municipality_of_Germany I've tried to describe the issue here: http://wiki.openstreetmap.org/wiki/Key:wikidata I've moved that to the talk page: https://wiki.openstreetmap.org/wiki/Talk:Key:wikidata and will reply there. I understood your further post in this manner: you want to take the Wikipedia link and add with a script or bot the associated Wikidata-ID. This would add the Wikidata ID Q3038 to both OSM objects place=island and boundary=administrative of Heligoland because both objects in OSM could link to the same Wikipedia article. That would be wrong because the ID of the island is Q17043877. Wikidata needs much consolidation. For example there existed only one object for Heligoland in Wikidata before i fixed it. The object in WD before described the island AND the municipality which is nonsense because the objects have a different area and so on. That's why I wrote it as one example on the Wiki-Page thus the mappers don't type in wrong Wikidata ID's. In Wikidata at the moment there is a big consolidation ongoing because there are also many duplicate objects. (Wikidata-objects were generated from Wikipedia-articles. When the Wikipedia articles of different language versions were not linked with Interwikilinks then there were created duplicate objects in Wikidata). In Germany we added the Wikidata-ID's to all administrative boundaries from AL 4-8: http://forum.openstreetmap.org/viewtopic.php?id=24168p=1 Here is a map with an overview where the wikidata-Tag is used: http://www.netzwolf.info/kartografie/karten/wikidata ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-de] Relation Harz (Mittelgebirge)
Am 10. Mai 2014 02:39 schrieb Frederik Ramm frede...@remote.org: Für uns ist es wichtig, dass im Zweifel jemand hingehen und die Sache verifizieren kann. Wie soll das gehen mit dem Harz? Da es sich beim Harz um ein Mittelgebirge handelt wird ein Mapper vor Ort wohl zumindest verifizieren können, dass da Berge stehen. Zieht man dann noch Höhendaten hinzu und liest die Definition von Mittelgebirgen auf Wikipedia dann kann selbst ich als Nicht-Geologe einigermaßen abschätzen wo ca. die Grenzen des Harz verlaufen. Nur weil etwas schwierig zu verifizieren ist kann das doch kein Grund sein, es nicht einzutragen. Manchmal muss man sich halt auch auf Experten verlassen die mehr Ahnung von der Materie haben. Wem die Grenzen zu ungenau sind der muss sie ja nicht nutzen. Einen Nutzen hat die Erfassung solcher Regionen durchaus, sei es für Karten, aber z.B. auch TMC hat Codes für Regionen, Unwetterwarnungen für bestimmte Regionen, ... Gruß Archer ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Harz (Mittelgebirge)
Am 10. Mai 2014 12:59 schrieb Christoph Hormann chris_horm...@gmx.de: On Saturday 10 May 2014, Archer wrote: Da es sich beim Harz um ein Mittelgebirge handelt wird ein Mapper vor Ort wohl zumindest verifizieren können, dass da Berge stehen. Zieht man dann noch Höhendaten hinzu und liest die Definition von Mittelgebirgen auf Wikipedia dann kann selbst ich als Nicht-Geologe einigermaßen abschätzen wo ca. die Grenzen des Harz verlaufen. Nur weil etwas schwierig zu verifizieren ist kann das doch kein Grund sein, es nicht einzutragen. Umgekehrt herum wird ein Schuh draus - nur weil etwas unzweifelhaft existiert bedeutet das noch lange nicht, das man es sinnvoll in OSM erfassen kann. Der Punkt hier ist, dass die einzige Möglichkeit, so etwas derzeit in OSM einzutragen, mittels eines Polygons ist - welches selbst dann, wenn man es nur 'ungefähr' einzeichnet mit großen Abständen zwischen den Nodes immer eine scharfe Grenze beschreibt und diese ist nicht verifizierbar. Das ist keine Frage von fehlender Fachkenntnis oder Aufwand bei der Ermittlung sondern liegt in der grundsätzlichen Natur der Sache, der Harz hat keine scharfe Grenze egal ob man ihn als geologische, topographische oder naturräumliche Einheit betrachtet. Es wären durchaus Methoden denkbar, solche Strukturen in OSM zu erfassen, beispielsweise könnte man einen Relationstyp vereinbaren, der einen inneren und einen äußeren Perimeter enthält. Der innere Perimeter wäre dadurch definiert, das alles innerhalb dessen unbestritten zur beschriebenen Region gehört und der äußere Perimeter würde festlegen, das alles außerhalb dessen unbestritten nicht dazu gehört. Der Raum zwischen den beiden Grenzen würde also gewissermaßen das Streuband aller Meinungen zur Abgrenzung des Gebietes darstellen. Die Frage ist allerdings natürlich, ob so etwas praktisch handhabbar ist - sowohl in der Erfassung als auch in der Auswertung. Und für die beiden Perimeter gäbe es individuell immer noch das Problem der Überprüfbarkeit, das würde durch eine solche Konstruktion zwar entschärft aber nicht wirklich gelöst. -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de Unscharfe Grenzen kommen doch in der Natur relativ häufig vor, z.B. die Waldgrenze/Baumgrenze. Erfasst werden Wälder in OSM trotzdem als Polygone. Irgendwo muss man halt einfach eine Grenze ziehen, auch wenn diese unter Umständen nicht optimal ist. Eine Lösung mit innerer und äußerer Perimeter hätte aber natürlich mehr Charme. Gruß Archer ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Harz (Mittelgebirge)
Es gibt ein Proposal für das Mappen von Gebirgen: http://wiki.openstreetmap.org/wiki/Proposed_features/Mountains Der Harz ist wohl ein Massiv laut Wikipedia: https://de.wikipedia.org/wiki/Gebirge#Gebirgsformen Den Harz könnte man also laut diesem Proposal mit natural=massif taggen. Oder du hälst dich an das Tagging, das in den Alpen angewandt wird mit region:type=mountain_area siehe z.B.: https://www.openstreetmap.org/relation/2127484 Es gab schon eine längere Diskussion zum Tagging von Gebirgen im Forum dazu: http://forum.openstreetmap.org/viewtopic.php?id=16094 Am 10. Mai 2014 16:09 schrieb Thorsten Alge li...@thorsten-alge.de: On 2014-05-9 16:33, Manuel Reimer wrote: On 05/09/2014 04:20 PM, Martin Koppenhoefer wrote: wieso ist das egal? Wenn ein Datentyp nicht geeignet ist, die Welt so zu beschreiben wie sie ist, dann sollte man es auch nicht damit machen... Warum sollte das nicht gehen? Die Grenzlinie wird einfach so gelegt wie es derjenige, der es einträgt, für richtig hält. Wenn das nicht passt kann das ja jederzeit noch korrigiert werden. Oder habe ich dich jetzt falsch verstanden? Es geht um die Tags die beschreiben, welche Art von Grenze es ist. Was eine sinnvolle Beschreibung des Grenzverlaufs angeht, habe ich lokal schon mal was aus den jetztigen Sachen angelegt. Allerdings ist das richtige Tagging noch unklar. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Harz (Mittelgebirge)
klar kann man Regionen erfassen, schau mal hier nach: http://forum.openstreetmap.org/viewtopic.php?id=24705 (da geht es u.a. auch um das Thema unscharfe Grenzen) Es gibt sogar eine Karte die Alpenregionen anzeigt basierend auf OSM-Daten: http://geo.dianacht.de/topo/?zoom=10lat=47.12089lon=11.35704 Am 9. Mai 2014 16:33 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: On 05/09/2014 04:20 PM, Martin Koppenhoefer wrote: wieso ist das egal? Wenn ein Datentyp nicht geeignet ist, die Welt so zu beschreiben wie sie ist, dann sollte man es auch nicht damit machen... Warum sollte das nicht gehen? Die Grenzlinie wird einfach so gelegt wie es derjenige, der es einträgt, für richtig hält. Wenn das nicht passt kann das ja jederzeit noch korrigiert werden. Oder habe ich dich jetzt falsch verstanden? Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konverter XErleben - OSM
Zu nennen wären auch noch die Seiten: http://wiki.openstreetmap.org/wiki/DE:How_to_map_a und http://wiki.osm.org/wiki/Map_Features Anmerkung: Die Definition auf den englischen Wikiseiten haben im Zweifelsfalle Vorrang vor der deutschen Übersetzung. Ihr nennt die Keys Cafe und Bauernhofcafe. Die sollten beide unter amenity=cafe zusammengefasst werden und gegebenenfalls das Bauernhofcafe durch einen zusätzlichen Key kenntlich gemacht werden. Neue Keys dafür einzuführen ist ungut, weil bestehende Anwendungen damit nicht umgehen können. Manchmal hilft auch das geschickte kombinieren von Tags weiter. Dann möchte ich noch auf die Tags tourism=yes (Wird benutzt um die touristische Bedeutung eines, durch andere Tags beschriebenen, Objektes anzugeben.) und tourism=attraction (Sehenswürdigkeit) aufmerksam machen: http://wiki.openstreetmap.org/wiki/DE:Key:tourism Damit könntet ihr z.B. euren Erlebnisbauernhof abbilden: landuse=farmyard + tourism=yes Es wäre aber auch denkbar bei Schaubrauereien (craft=brewery + tourism=yes) und anderen Sachen. Den Key leisure=swimming_pool habt ihr offenbar etwas falsch verstanden, damit werden lediglich einzelne Schwimmbecken eingezeichnet. Das Thema Seezeichen ist ziemlich komplex: http://wiki.openstreetmap.org/wiki/Marine_navigation http://wiki.openstreetmap.org/wiki/OpenSeaMap/Landmarks http://wiki.openstreetmap.org/wiki/OpenSeaMap/Lights http://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Tag_Values Ich weiß nicht, inwiefern das Thema für euch wichtig ist. Schließt euch da am besten mit den Machern von OpenSeaMap kurz. In dem Bereich fanden auch schon einige Importe statt. Am 3. April 2014 13:03 schrieb René Falk li...@falconaerie.de: Am 03.04.2014 11:31, schrieb EFTAS Christian Röttger: Hallo liebe OSM-Community, Hallo, Bei der Zuordnung der Brennerei kommen wir zu dem ersten Problem. In der offiziellenMap Features Liste (http://wiki.osm.org/wiki/DE:Map_Features) gibt es noch keinen entsprechenden Tag um diese Funktion eines POI zu beschreiben. Weil nicht eindeutige Zuordnungen häufiger auftauchen hoffen wir auf die Zusammenarbeit mit der OSM Community. Die Lösung könnte z.B. die Einführung neuer Tags sein, aber da sind wir für alle Lösungsvorschläge offen und dankbar. Die Map Features beinhalten nicht alle tags, und man sollte sich nicht daran klammern. Bei nicht vorhandenen tags in DE:Mapfeatures solltet ihr sprachunabhängig suchen, beispielsweise gibt es ein craft=brewery schon, wie ihr vielleicht schon gemerkt habt. http://wiki.openstreetmap.org/wiki/Tag:craft%3Dbrewery Unsere Idee ist, diese Zuordnungsliste frei verfügbar zu machen (z.B. auf einer Seite im OSM Wiki) und dort zu pflegen, um anderen Kommunen, Personen, etc. Hilfestellung beim Import/Export von Daten in OSM zu ermöglichen. Eine erste Arbeitsversion befindet sich momentan unter https://docs.google.com/file/d/0B5hzMGhyvOK6c1dDQ21pYUxZZFE. Aber es existieren noch viele leere Zeilen (s.o.) und Unklarheiten, welche Tag-Kombinationen die Richtigen sind. Hier hoffen wir auf den Input der erfahreneren OSM Mapper, um gemeinsam diese Lücken zu füllen. Evtl. haben wir als schönen Nebeneffekt, dass das Wiki in Bereichen mit leicht widersprüchlichen Angaben harmonisiert wird. Mit taginfo lassen sich tags überprüfen (z.B. Wie oft benutzt? ; Mit welchen Kombinationen? ; usw.) http://taginfo.openstreetmap.org Ich habe jedoch Zweifel, ob für Kombinationen nur ein zusätzliches Wertepaar ausreicht. Da müsste man schon Wissen welche Infos für euch in der Kombination relevant sind. Beispielsweise amenity=restaurant, da gibt es einige mögliche zusätzliche Infos wie z.B. Name, Öffnungszeiten, Art der Küche, Rauchen, Rollstuhltauglichkeit, WLan, usw. Wie wollt ihr diese Problematik lösen? http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drestaurant Mit freundlichen Grüßen Christian Röttger Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konverter XErleben - OSM
Zur Brennerei findet man unter How to map a folgende Anmerkung: Brennerei: craft=distillery + distillery=* Am 3. April 2014 17:16 schrieb EFTAS Christian Röttger christian.roett...@eftas.com: Hallo, diese aktuelle Tabelle ist nur zur Kategorisierung gedacht. Tags wie name, adresse, etc. sollen natürlich als normale Attribute mit übernommen werden aber nicht unbedingt der Kategorisierung dienen. Wir haben uns erst einmal an den Map Features entlang geangelt, hauptsächlich in Englisch und auch Seiten wie http://wiki.openstreetmap.org/wiki/DE:How_to_map_a und http://wiki.osm.org/wiki/Map_Features zum besseren Verständniss. Auch TagInfo hat die ein oder andere Info gebracht. Das Thema ist halt sehr komplex und kann sich nur sukzessiv entwickeln. Craft: brewery benutzen wir ja auch für eine Brauerei. Aber für eine Destillerie passt es nicht unbedingt. Auch kann man natürlich zu jedem Tag eine eigene Diskussion aufmachen, da es diverse Meinungen und Sichtweisen gibt. Wir möchten versuchen daraus einen recht ordentlichen Konsens zu schaffen. Viele Grüße Christian Betreff: Re: [Talk-de] Konverter XErleben - OSM Am 03.04.2014 11:31, schrieb EFTAS Christian Röttger: Hallo liebe OSM-Community, Hallo, Bei der Zuordnung der Brennerei kommen wir zu dem ersten Problem. In der offiziellenMap Features Liste (http://wiki.osm.org/wiki/DE:Map_Features) gibt es noch keinen entsprechenden Tag um diese Funktion eines POI zu beschreiben. Weil nicht eindeutige Zuordnungen häufiger auftauchen hoffen wir auf die Zusammenarbeit mit der OSM Community. Die Lösung könnte z.B. die Einführung neuer Tags sein, aber da sind wir für alle Lösungsvorschläge offen und dankbar. Die Map Features beinhalten nicht alle tags, und man sollte sich nicht daran klammern. Bei nicht vorhandenen tags in DE:Mapfeatures solltet ihr sprachunabhängig suchen, beispielsweise gibt es ein craft=brewery schon, wie ihr vielleicht schon gemerkt habt. http://wiki.openstreetmap.org/wiki/Tag:craft%3Dbrewery Unsere Idee ist, diese Zuordnungsliste frei verfügbar zu machen (z.B. auf einer Seite im OSM Wiki) und dort zu pflegen, um anderen Kommunen, Personen, etc. Hilfestellung beim Import/Export von Daten in OSM zu ermöglichen. Eine erste Arbeitsversion befindet sich momentan unter https://docs.google.com/file/d/0B5hzMGhyvOK6c1dDQ21pYUxZZFE. Aber es existieren noch viele leere Zeilen (s.o.) und Unklarheiten, welche Tag-Kombinationen die Richtigen sind. Hier hoffen wir auf den Input der erfahreneren OSM Mapper, um gemeinsam diese Lücken zu füllen. Evtl. haben wir als schönen Nebeneffekt, dass das Wiki in Bereichen mit leicht widersprüchlichen Angaben harmonisiert wird. Mit taginfo lassen sich tags überprüfen (z.B. Wie oft benutzt? ; Mit welchen Kombinationen? ; usw.) http://taginfo.openstreetmap.org Ich habe jedoch Zweifel, ob für Kombinationen nur ein zusätzliches Wertepaar ausreicht. Da müsste man schon Wissen welche Infos für euch in der Kombination relevant sind. Beispielsweise amenity=restaurant, da gibt es einige mögliche zusätzliche Infos wie z.B. Name, Öffnungszeiten, Art der Küche, Rauchen, Rollstuhltauglichkeit, WLan, usw. Wie wollt ihr diese Problematik lösen? http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drestaurant Mit freundlichen Grüßen Christian Röttger Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Meiner Meinung nach sollte man die Hochsitze nicht löschen, um keinen Präzedenzfall zu schaffen. Die Erfassung von Hochsitzen ist datenschutzrechtlich nicht zu beanstanden. Demnächst fordert dann jemand, wir sollten Höhlen aus OSM löschen (wie kürzlich bei Wikipedia geschehen) oder irgendein anderes Feature, weil das böse OSM angeblich zu Straftaten anstiftet/Hilfe leistet. Einen Beweis bleibt der Herr natürlich schuldig, oder hat er mit den noch nicht gefassten Tätern gesprochen? Am besten löschen wir auch gleich noch die Waldwege, damit sich auch ja niemand mehr im Wald orientieren kann. Bei der Beschädigung von Hochsitzen handelt es sich um eine strafbare Handlung. Man sollte dem Herrn daher ans Herz legen, diese bei der Polizei zur Anzeige zu bringen. Gruß Archer Am 14. März 2014 18:38 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 14. März 2014 18:11 schrieb Stephan Wolff s.wo...@web.de: Wir sollten in wenigen Einzelfällen auf Eintragungen in OSM verzichten, auch wenn kein gesetzlicher Anspruch darauf besteht. ja, aber darum geht es ja gar nicht. Klar trägt jeder nur das ein, was ihm sinnvoll vorkommt, und das er verantworten kann. Es geht hier darum, dass jemand darum gebeten hat, das von anderen eingetragene wieder zu löschen. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bodendenkmal wie geht das?
In OpenStreetMap sind so viele Daten enthalten, dass es unmöglich ist, alles auf einer Karte darzustellen. Die Macher der Standardkarte von openstreetmap.org haben sich wohl dagegen entschieden, Burgen darzustellen. Verbesserungsvorschläge für den Kartenstil auf openstreetmap.org kann man hier einbringen: https://github.com/gravitystorm/openstreetmap-carto/issues Die Karte von openstreetmap.de stellt alte Burgen als Symbol dar, wenn sie richtig getaggt wurden: http://openstreetmap.de/karte.html Außerdem gibt es noch die Geschichtskarte, die ebenfalls auf OpenStreetMap-Daten basiert, hier werden historische Objekte besonders hervorgehoben: http://geschichtskarten.openstreetmap.de/historische_objekte/ Bitte beachte, dass Burgen mit historic=castle + castle_type=defensive + (falls Ruine): ruins=yes getaggt werden, siehe hier: http://wiki.openstreetmap.org/wiki/Historical_Objects/Map_Properties Außerdem sollten im Namen eines Objektes auch wirklich nur der Name und keinerlei darüber hinausgehende Informationen wie Wüstung, Bodendenkmal o.ä. stehen. Das sollte man über weiterführende Tags abbilden, siehe auch: http://wiki.openstreetmap.org/wiki/DE:Names#name_ist_nur_der_Name Für geschützte Gebiete gibt es folgendes Taggingschema: http://wiki.openstreetmap.org/wiki/DE:Tag:boundary%3Dprotected_area Gruß Archer Am 7. März 2014 12:26 schrieb Caronna eifelhu...@gmx.de: Hallo, ich brauchte noch mal Hilfe. Simmerath hat ein Bodendenkmal unter Schutz gestellt: http://www.openstreetmap.org/#map=19/50.58976/6.31062 in Josm hab ich das eingetragen, auch in Potlach ist da nun zu erkennen, nur in OSM nicht. Ich habe es mal als Kreis dargestellt, weil ich dachte ein Punkt kommt nicht so einfach durch. Problem ist auch das das Bodendenkmal, eine alte Burganlage, so gut wie nicht zu erkennen ist (soll vor 20 Jahren noch anders gewesen sein, Gräbern sollen noch deutlich zu erkennen gewesen sein, evtl auch Mauerreste) Eigentlich hätte ich den Ort gerne durch eine Schraffierung gekennzeichnet, finde aber nicht dazu. Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Wenn du den Standard-OSM-Stil meinst, dann kannst du Verbesserungsvorschläge/Fehler hier melden: https://github.com/gravitystorm/openstreetmap-carto/issues Der Grund ist, dass der Style umgebaut wird. Siehe auch folgende Fehlermeldung: https://github.com/gravitystorm/openstreetmap-carto/issues/355 Gruß Archer Am 24. Februar 2014 23:45 schrieb Bernhard Weiskopf bweisk...@gmx.de: Heute ist mir aufgefallen, dass die Mapnik-Karte keine Namen von Flächen (area = yes und name = ...) mehr anzeigt, aber auch keine Namen mehr von service roads und von tracks. Nur in Zoomstufe 19 werden sie manchmal, dann aber auch oft bruchstückhaft, gezeigt. Nachdem in Mannheim die Namen der Quadrate (quasi unsere Straßennamen) nicht mehr angezeigt werden, fehlen jetzt auch noch die Namen aller Waldwege und der kleinen Zufahrtsstraßen, die teilweise eigene Namen tragen. Im hiesigen Naherholungsgebiet Käfertaler Wald tragen viele Straßen und Wege Namen, die an den Wegkreuzungen und dem zentralen Karlstern angeschrieben sind. Die müssen auch auf der Karte erscheinen. Kennt jemand den Grund? Wird das so weitergehen, dass man sich mit den üblichen OSM-Karten bald nirgends mehr orientieren kann? Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutsche Ortsnamen in Osteuropa
Du kannst ja gerne einzelne nazionalsozialistisch geprägte Ortsnamen auf old_name abändern. Oder Orte, bei denen es einen neueren Deutschen Namen gibt entsprechend ergänzen, aber nicht alle Namen! Bestes Beispiel ist das von dir umbenannte Český Krumlov (zu Deutsch: Krumau). Das wird zumindest in Bayern immer noch so genannt! Český = Böhmisch, Krumlov = Krumau. Ich bin zwar kein Sprachwissenschaftler, aber ich denke mal der Name könnte von den Deutschen Ostsiedelungen[1] her stammen. Das war lange vor der Nazizeit, das Argument politisch auch etwas fragwürdig erscheinen zieht also nicht. Gruß Archer [1]https://de.wikipedia.org/wiki/Deutsche_Ostsiedlung Am 22. Januar 2014 08:12 schrieb jotpe jotpe@gmail.com: Deutscher und einheimischer Namen haben eine gewissen Ähnlichkeit. Das halte ich eher für ein Argument es so zzu belassen. Ansonsten vielleicht davon abhängig machen, ob die Stadt einen zweiten deutschen Namen offiziell besitzt, oder wie groß die deutschstämmige Einwohnerzahl noch ist. Gruß Johannes ## Český Krumlov (Krumau) - http://www.openstreetmap.org/node/1599136536/history - http://openstreetmap.de/karte.html?zoom=13lat=48.80904lon=14.32547layers=B000TT ## Suchdol nad Lužnicí (Suchenthal) - http://www.openstreetmap.org/node/1599164429/history - http://openstreetmap.de/karte.html?zoom=11lat=48.87789lon=14.91598layers=B000TT ## Volary (Wallern) http://www.openstreetmap.org/node/1599209595/history http://openstreetmap.de/karte.html?zoom=12lat=48.90803lon=13.88911layers=B000TT Am 22. Januar 2014 07:15 schrieb jotpe jotpe@gmail.com: Über ein fernes Osteuropa könnte man evtl drüber reden. Ich persönlich finde, dass generell der Name:de Tag bleiben sollte. In Polen würde ich sowas überhaupt nicht machen. Da sind so ziemlich alle etwas größeren Städte mit deutschen Namen in Unterhaltungen total üblich. Danzig, Krakau, Kattowitz .. Gruß Johannes Am Mittwoch, 22. Januar 2014 schrieb Roland Olbricht : Hallo zusammen, Ich würde gerne eine breit angelegte Aufräumaktion vorschlagen, bei der wir alle name:de keys in old_name:de verwandeln. Die Änderungen wären auf ein noch genauer zu definierendes Gebiet und für Orte unter einer noch genauer zu definierenden Einwohnerzahl (zb 500 000) beschränkt. Findet Nominatim den Schlüssel old_name:de? Tourismus ist zumindest nahe der Ostsee-Küste ein relevanter Wirtschaftszweig, und daher möchte manche Stadt auch anhand des alten deutschen Namens zuverlässig gefunden werden. Was sagt die jeweilige lokale Community? Die polnische hat auf jeden Fall gerade einen missglückten Massenedit abbekommen. Da müsste eine solche Änderung unbedingt in jedem Fall zuerst vor Ort diskutiert werden. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutsche Ortsnamen in Osteuropa
Einfach den Rasenmäher anwerfen und einmal Querbeet alle deutschen Namen rausschmeißen halte ich jedenfalls für falsch. Alles in allem ist es eine recht subjektive Einschätzung, wie ein Ort genannt wird und unterscheidet sich je nach Mapper (Alter, Wohnort, ...). Meine Oma wird mir andere Ortsnamen nennen können, die mir z.B. nicht mehr geläufig sind. Hier in Niederbayern heißt Český Krumlov jedenfalls immer noch Krumau, Plzeň = Pilsen und Klatovy = Klattau. Soweit ich mich erinnern kann steht sogar auf den Verkehrsschildern Pilsen. Am elegantesten wäre es, wenn in einer Karte beide Namen dargestellt würden. Dann versteht jeder was gemeint ist. Gruß Archer Am 22. Januar 2014 01:24 schrieb Alex Barth a...@mapbox.com: Ich würde gerne einen Verbesserungsvorschlag zu deutschen Ortsnamen in Osteuropa machen. Ich bin mir sicher dieses Thema ist schon einmal aufgekommen. Viele ehemalig deutschsprachige Gegenden in Osteuropa zeigen nicht mehr gebräuchliche deutsche Ortsnamen. Dies lässt OpenStreetMap auf Deutsch nicht nur veraltert sondern politisch auch etwas fragwürdig erscheinen - vor allem wenn man einen allgemeinen, nicht historisch-akademischen, Gebrauch annimmt. Hier sind zwei Beispielgegenden: - Deutsche Ortsnamen in Rumänien http://openstreetmap.de/karte.html?zoom=9lat=45.9887lon=24.44216layers=B000TT - Deutsche Ortsnamen in Tschechien http://openstreetmap.de/karte.html?zoom=11lat=50.31376lon=13.79744layers=B000TT - Kroatien: http://openstreetmap.de/karte.html?zoom=12lat=45.16566lon=18.01446layers=B000TT Ich würde gerne eine breit angelegte Aufräumaktion vorschlagen, bei der wir alle name:de keys in old_name:de verwandeln. Die Änderungen wären auf ein noch genauer zu definierendes Gebiet und für Orte unter einer noch genauer zu definierenden Einwohnerzahl (zb 500 000) beschränkt. Das würde die jetzige Situation, in der die deutschen Städtenamen in Osteuropa schlichtweg nicht verwendbar sind, deutlich verbessern. Da dies ein weitgehendes und systematisches Problem in OpenStreetMap darstellt, schlage ich bewusst einen konzertierten Ansatz vor. Wie steht ihr dazu? Hier sind drei entsprechende Veränderungen die ich in Gegenden die ich selbst kenne vorgenommen habe: ## Český Krumlov (Krumau) - http://www.openstreetmap.org/node/1599136536/history - http://openstreetmap.de/karte.html?zoom=13lat=48.80904lon=14.32547layers=B000TT ## Suchdol nad Lužnicí (Suchenthal) - http://www.openstreetmap.org/node/1599164429/history - http://openstreetmap.de/karte.html?zoom=11lat=48.87789lon=14.91598layers=B000TT ## Volary (Wallern) http://www.openstreetmap.org/node/1599209595/history http://openstreetmap.de/karte.html?zoom=12lat=48.90803lon=13.88911layers=B000TT ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutsche Ortsnamen in Osteuropa
Das war eher als Anregung für Alex von Mapbox gedacht, um das Problem mit etwaigen etwas angestaubten Namen zu entschärfen ;) Ich finde es ja allein schon toll, dass es überhaupt eine deutsche OSM-Karte gibt. Das erleichtert vieles, vor allem in Ländern mit anderen Schriftzeichen, der Fragestellung wo fehlt noch die deutsche Übersetzung?, ... Gruß Archer Am 22. Januar 2014 14:40 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Archer arc...@gulli.com wrote: Am elegantesten wäre es, wenn in einer Karte beide Namen dargestellt würden. Ich finde meine Logik ist auch ohne soetwas schon kompliziert genug: http://svn.openstreetmap.org/applications/rendering/mapnik-german/views/get_localized_name.sql Du darfst mir gerne eine andere Logik bauen die das von Dir gewünschte implementiert. Den lokalen namen in Klamemr zu setzen wäre zwar nett, aber das müsste IMO in kleinerer Schrift sein und das geht meines Wissens zumindest mit der aktuellen Technik nicht. Gruss Sven -- Software is like sex; it's better when it's free (Linus Torvalds) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutsche Ortsnamen in Osteuropa
Am 22. Januar 2014 14:11 schrieb Alex Barth a...@mapbox.com: Also im grossen und ganzen ist der Tenor der Kommentare so lassen wie's ist da eine Veraenderung nach allgemeinen Regeln zu Faellen fuehren wuerde in denen gebraeuchliche Namen entfernt wuerden. Wie sähen allgemeine Regeln für dich aus? Wann ist ein Name anachronistisch? Wie soll man als Mapper einschätzen, ob der Name anachronistisch ist? Ich sehe das eher so, dass man den Deutschen Namen stehen lässt, außer der deutsche Name ändert sich, z.B. Stalingrad -- Wolgograd und dann erst in old_name verschiebt. Aber ist es nicht so, dass die jetzigen name:de Ortsnamen in Osteuropaeischen Laendern so anachronistisch wirken dass ein (optimierter) Reset ein besserer Ansatz waere? Die deutsche Karte allgemein besser benutzbar machen wuerde? You have to break an egg to make an omelette... Da muss ich dir bei manchen Ortsnamen zustimmen, aber wie gesagt, das ist immer auch ein teils subjektiver Eindruck. Nur weil man den Namen selbst nicht kennt, muss es ja nicht gleich heißen, dass er nicht mehr im deutschen Sprachgebrauch verwendet wird. Was gaebe es fuer bessere Loesungen? Lokalen und deutschen Namen in die Karte packen. Dann versteht jeder was gemeint ist. Cheers - Alex PS: Bestes Beispiel ist das von dir umbenannte Český Krumlov (zu Deutsch: Krumau). Das wird zumindest in Bayern immer noch so genannt! Grossartiges Beispiel woran's in OSM zur Zeit hapert. Český Krumlov wird auch in Oberoesterreich allgemein Krumau genannt, aber sicher nicht Boehmisch Krumau, der name:de den ich entfernt habe. 2014/1/22 chris66 chris66...@gmx.de Am 22.01.2014 13:28, schrieb Archer: Am elegantesten wäre es, wenn in einer Karte beide Namen dargestellt würden. Dann versteht jeder was gemeint ist. Ja, und wir haben ja bereits mindestens eine Karte die diese ganzen Namen auch anzeigen kann. such, such, such Hier: http://toolserver.org/~osm/locale/ war sie mal (funzt nicht mehr). Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[talk-ph] Trying to get in touch with Mike Collinson who was in Tokyo in the 1980s
Mike, Are you there? I am putting together videos I took of the Tokyo Hash in the 1980s. You feature but no-one has your e-mail address. Guillermo gave me an old address m...@asiadata.com. But it does not work. Steve Archer ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
