Re: [OSM-talk] OSM-Garmin relationship?
Greg Troxel g...@ir.bbn.com writes: I would guess that the 'warranty' comment is just the typical corporate reaction to questions of liability, perhaps combined with a lack of understanding of open data. Especially when you consider that when you turn on your device you get a warning saying All information is presented for reference only. You assume total responsibility and risk associated with using this device. (at least mine does that.) So there is no warranty for the data anyway. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] ebook-Karte auf Kindle
Fabian Schmidt fschm...@informatik.uni-leipzig.de schrieb: Hallo, Am 27.06.11 schrieb Wolfgang Barth: Was ich mich schon immer gefragt habe war, warum es kein GPS-Gerät mit e-paper Anzeige gibt. Auch diese transflexiven Displays sind bei Sonnenlicht nur schlecht ablesbar. Für Outdoor-Geräte die man bei Tag nutzen will, wäre E-Paper die erste Wahl, auch wenn man keine Farbe, sondern nur Graustufen darstellen kann. Also ich habe mit meinem Garmin GPSmap 60 keine Probleme bei Sonnenschein. Das funktioniert so gut, dass ich mich immer frage, warum niemand solche Displays in Handies einbaut. Wenn es Probleme bei Sonnenlicht gibt, liegt das eventuell an ungenügender Entspiegelung der Oberfläche. Prinzipiell kann das aber auch bei E-Paper passieren. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ebook-Karte auf Kindle
Fabian Schmidt fschm...@informatik.uni-leipzig.de schrieb: Am 27.06.11 schrieb Matthias Julius: Also ich habe mit meinem Garmin GPSmap 60 keine Probleme bei Sonnenschein. Das funktioniert so gut, dass ich mich immer frage, warum niemand solche Displays in Handies einbaut. - kein Smartphone-Hersteller würde auf ein Touchpad verzichten Schließen sich Touchscreen und transflektives Display gegenseitig aus? - die Handytester sitzen drinnen und schreiben über Kontrast und Auflösung In fast jeder c't z.B. wird die teilweise Unbrauchbarkeit von Handies, Tablets und Notebooks im Freien bemängelt. Sollte diese Kritik noch nicht bis zu den Herstellern durchgedrungen sein? Wenn es Probleme bei Sonnenlicht gibt, liegt das eventuell an ungenügender Entspiegelung der Oberfläche. Prinzipiell kann das aber auch bei E-Paper passieren. Ich nehme an, dass Dein GPSMap nicht wesentlich entspiegelt ist. Es versteht einfach besser, mit statt gegen die Sonne zu arbeiten[1]. Wirklich entspiegelt ist es nicht. Es kommt halt auf das Verhältnis der Lichtmengen an, die ober- und unterhalb des Flüssigkristalls reflektiert werden. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder für JOSM
malenki o...@malenki.ch writes: Stephan Knauss schrieb: Da die Bilder allerdings aus vielen Einzelbildern zusammengesetzt werden kann sich der Versatz nach ein paar Kilometern geändert haben. Soweit ich weiß, werden alle Bilder mit einem Höhendatenmodell nachberechnet, um Verzerrungen zu eliminieren. (Veranschaulichung: stell dir einen auf die Zugspitze führenden Weg mit Serpentinen vor). Viele der Bing-Bilder wurden aber nicht aus der Senkrechten aufgenommen. Die Folge sind teilweise erhebliche Abweichungen auch innerhalb kleine Gebiete. Genau, die Variation des Versatzes hat nichts damit zu tun, dass es viele Einzelbilder sind (abgesehen von Ungenauigkeiten bei der Entzerrung und eventuellen Fehlern, die dabei gemacht werden). Die Güte der Entzerrung hängt vielmehr von der Genauigkeit des Höhenmodells ab, das dabei verwendet wurde. Die meisten Pixel wurden ja nicht genau senkrecht von oben fotografiert, sondern schräg. Das sieht man sehr schön an hohen Gebäuden, Schornsteinen oder ähnlichem. Dort deckt sich auf den Luftbildern das Dach meist nicht mit dem Grundriss. Da muss man eben aufpassen, dass man den Grundriss mappt und nicht das Dach. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Pitiful proceedings - as usual
Michael Collinson m...@ayeltd.biz schrieb: The link looks good. I'll make sure any future license change related stuff goes here as well as our normal announce mailings. For me the preferred and most natural way of receiving announcements is the announce mailing list. Announcements on talk might get drowned in all the other traffic about the license change process. :/) Subscribing to announce should be strongly recommended to everyone. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Pitiful proceedings - as usual
NopMap ekkeh...@gmx.de schrieb: Hi! Frederik Ramm wrote: Well there was an announcement on 14th June on this list and others by Mike Collinson saying that we intend to move to phase 4 this Sunday 19th June or as soon after as is technically practical. For anyone who had already agreed, this date passed unnoticed. What exactly did you miss - would you have liked another email that said ok, we've really implemented it now? Yes, exactly. As you properly quoted or as soon... makes this statement rather vague. I have read that to mean We will switch to phase 4 unless there are technical problems. Frederik Ramm wrote: Given that the clear intent to switch to phase 4 on Sunday was widely published, was that not enough? A clear no to this. We intend to ... or maybe later contains no statement about whether anything has happened. I believe you noted the guesses and questions on the matter in the German forum yesterday, the question on this list... How difficult is it to guess what happened if you have read the above announcement and on the following day you can not upload anymore and coincidentally you have declined the CTs? Or is anyone saying I know they intended ro switch to pase 4, but, when I could not upload I did not realize they really did.? If someone did not read the original announcement he probably would not read the next one neither. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bing aerial imagery priorities
David Murn da...@incanberra.com.au writes: On Fri, 2011-06-17 at 09:16 -0500, Toby Murray wrote: On Thu, Jun 16, 2011 at 10:19 PM, David Murn da...@incanberra.com.au wrote: when all the nearmap-derived data is removed It seems like you missed an email a couple of days ago? Current NearMap derived data does not need to be removed from OSM during the license change. It sounds like you mis-read the email. It does not 'need' to be removed, NearMap have simply said it CAN be relicenced, depending on the user who derived the data. Unless a user can guarantee that their edits were 100% based on nearmap and used no other CC source (unlikely for Australian users), they cant accept the CTs, which means all their edits must be removed. Wasn't there a requirement to attribute Nearmap derived data? Where that has been done the data could be saved. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bing aerial imagery priorities
Steve Coast st...@asklater.com schrieb: I'm speaking personally and there are no guarantees here but I'd like to get input on what areas you would like Bing to prioritise for aerial and/or satellite imagery in the coming year. Large areas of Switzerland have pretty low resolution. A couple cities have really good coverage. But, in between it is poor. I am particular interested in the area around Thun. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Users who disagree to ODbL but want PD / CC0
Dermot McNally derm...@gmail.com writes: On 16 June 2011 18:55, Robert Kaiser ka...@kairo.at wrote: I know at least one person who does exactly that just because he wants to harm the OSMF because he disagrees with the processes - not with the outcome, though. The harm he's doing is to the other mappers in the areas he has mapped. It does not matter why someone decides to not agree to the CT but still releases his data into PD. It is enough that people like that exist and we need to deal with that. And to argue that they should agree to the CT and then forget OSM is not going to help. There are probably also people that have stated somewhere that their data is PD and later disappeared. It would be a pity to loose all the data of those people. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Wanderwegeverlauf und Kartenwerk der Landesvermessung
Johannes Huesing johan...@huesing.name writes: Manuel Reimer manuel.s...@nurfuerspam.de [Mon, May 30, 2011 at 08:12:52PM CEST]: André Joost wrote: Ein Tourismusverband, der unbedingt *seine* Rechte *nicht* weitergeben will, kann uns daher u.U. einen Strick draus drehen, wenn wir einfach *alle* Wanderwege aus den Karten der Landesvermessung übernehmen. Kann er nicht. Wege, die mit Wanderzeichen gekennzeichnet sind, können auch ohne importierte Daten erfasst werden. Der französische Wanderverband ist da sehr beißwütig und hat sich unter anderem die Abkürzung GR für Grande Randonée als Marke schützen lassen. Na und? Das heisst doch nur, dass man die Marke nicht für etwas anderes verwenden darf. Wenn man also eine geschützte Marke genauso verwendet wie der Markeninhaber, wird das ja wohl kein Markenrechtsverstoss sein. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Ulf Lamping ulf.lamp...@googlemail.com writes: P.S: Neulich bei Amazon gesehen: MARCO POLO Karten 1:150.000 Kreta: Mit landwirtschaftlich schönen Strecken ... :-) Rapsfelder z.B. sind doch recht nett anzusehen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Geofabrik Download Server Update
Frederik Ramm frede...@remote.org schrieb: Hi, On 05/19/2011 06:44 AM, Hermann Peifer wrote: Are the boundary polygons that you use for clipping available somewhere? I do vaguely remember that I have seen them earlier, but I can't find them anymore. No, they aren't publicly available but I send them to people on request. There's really no reason to keep them secret, I just haven't set up a mechanism to automatically put them on the server because I didn't think people were all that interested. Are they so much in flux that simply putting them on a web server won't do as a mechanism? If you publish them you might get patches to eliminate those occasional spots of no-man's-land you were referring to in an earlier mail. One thing people might be interested in doing is to merge them and use the result for extracting where the geofabrik extracts are not mergeable. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Geofabrik Download Server Update
Frederik Ramm frede...@remote.org schrieb: Hi, Matthias Julius wrote: One option would be to run osmosis with clipIncompleteEntities=false (the default). That would not increase the burden on your box and still allow the extracts to be merged. Of course, this would leave it up to the data consumer to deal with the incomplete ways and relations. Yes. I somewhat fear the number of i am getting a strange error in my program emails that this would cause. Yes, that is why there would need to be a tool that can trim incomplete ways. Maybe as an osmosis task. Merging extracts is a niche operation and not the main purpose of what I am doing. Is it that small of a niche? There are probably plenty of reasons why someone might be interested in an area that crosses an extract boundary. You might save a lot of bandwidth if people who for example want to produce a Garmin map for BeNeLux do not ha e to download the whole of Europe. ;-) Of course, this all speculation. Maybe I am the only one that cares for mergeable extracts. For someone who wants to mix and merge at will, it would be much better to simply divide the world in lots of squares and select from those. The expensive polygon cutting could be dropped completely. It is possible that a process for doing that can be derived from those who do regular Garmin maps. If done properly, it would even be possible to have a web interface where you can select your area of interest, and a matching extract is then merged live from pre-made squares... In some ways this is even preferable because it would preserve the boundary of the extract. Otherewise you get a fuzzy boundary and the consuming tools have no way of knowing the original boundary. Yes but if you start looking at this closely then the only thing you know is that the boundary must be somewhere between nodes X and Y so that doesn't get you far. It is more a cosmetic thing. If for example someone wants to render a map for a certain extract they will have some long ways sticking out here and there, which is ugly. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Garmin: Mehrere Länder in einer gmapsupp.img?
Joerg Fischer o...@jfis.de schrieb: NopMap wrote: http://forum.openstreetmap.org/viewtopic.php?id=11792-- Dnke. Der Tipp zu osmchange war genau das was ich brauchte. Für den geneigten Mitleser: Entgegen seinem Namen ist osmchange nicht nur für das Nachziehen von täglichen Differenzen, es kann auch *.osm zusammen führen: | osmchange64 czech_republic.osm poland.osm austria.osm \ | switzerland.osm italy.osm germany.osm DACHIPLCZ.osm Anschließend verfüttere ich das Ergebnis wie immer an mkgmap und es funktioniert perfekt. In Vorbereitung der Urlaubssaison kann ich jetzt die für mich relevanten Länder auf 2GB quetschen. :-) Dank auch an Martin! Hast Du Dir das Ergebnis mal genau angesehen? Die Extrakte der Geofabrik sind (abgesehen von den Bundesländern) nicht für das Zusammenführen geeignet, da die Wege an der Grenze beschnitten werden. Und je nachdem, wie das Zusammenführen funktioniert, hat man dann eventuell Lücken oder fehlende Wege auf einer Seite der Grenze. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Geofabrik Download Server Update
Kai Krueger kakrue...@gmail.com schrieb: Altogether, I think those daily country extracts are one of the most useful tools for working with OSM data, so I'd like to send a great thanks to Geofabrik for providing the resource to offer this valuable service. I agree. But, I need to point out again that theese extracts are not quite as useful as they could be, IMHO. Unless something has been changed, ways that cross the bounding polygon are trunkated at the last node inside the polygon. When two neighboring extracts are merged there will be a gap at the border (or worse). This makes the extracts unusable if one needs a little bit more than one. Merging of two extracts is much easier and resource friendlier than downloading the bigger extract and extracting the data from that. I know it has been stated before that the Geofabrik extracts are as they are to maintain backwards compatibility. One could provide a little tool or osmosis filter (if that doesn't exist, yet) that trunkates incomplete ways for tools that cannot cope with those on their own. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Geofabrik Download Server Update
Frederik Ramm frede...@remote.org writes: Matthias, Matthias Julius wrote: But, I need to point out again that theese extracts are not quite as useful as they could be, IMHO. Unless something has been changed, ways that cross the bounding polygon are trunkated at the last node inside the polygon. I have started to slowly introduce extracts built with the --complete-ways option, but not all extracts have that yet. In Europe, all sub-country extracts have it but countries don't, so you should be able to join two German Laender or two French regions, but you will encounter problems when joining a part of Germany with a part of France. I'm working on that but even a box with 90 GB of RAM disk has a hard time splitting Europe into countries with --complete-ways. One option would be to run osmosis with clipIncompleteEntities=false (the default). That would not increase the burden on your box and still allow the extracts to be merged. Of course, this would leave it up to the data consumer to deal with the incomplete ways and relations. In some ways this is even preferable because it would preserve the boundary of the extract. Otherewise you get a fuzzy boundary and the consuming tools have no way of knowing the original boundary. Alternatively, the boundary polygon could be stored in the file. Unfortunately, so far the file formats only support rectangular bounding boxes. Note that two other preconditions exist for a successful join of neighbouring regions. First, the polygons I use for cutting must actually overlap. They usually do but every now and then I encounter a little bit of no man's land due to polygon simplification. Second, you have to use software that properly eliminates the double elements; I'm not sure if Osmosis does that. If it doesn't than this is the chance to fix it. Do your polygons really overlap? I think it would be ideal if the shared the nodes. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Share Alike für Datenbanken mit Vektordaten
Simon Poole si...@poole.ch writes: Was soll das Problem sein (hat Fredierik aber auch schon in Detail aufgezeigt)? a) aus Eigeninteresse wird wohl was zurückfliessen, denn was nützen Karten die nicht aktuell gehalten werden. Was soll zurückfliessen? Das Aktuellhalten erledigt ja OSM. b) ist es jedem anderen Navi Hersteller freigestellt die Daten auch zu nehmen und die Karten zu besseren, vielleicht auch freieren Konditionen anzubieten. c) hab ich grundsätzlich kein Problem damit, wenn Firmen Geschäftmodelle verfolgen mit dem sie Geld verdienen, anstatt solche mit denen Sie nichts verdienen. Wenn das Geschäftsmodell nur darin besteht, OSM-Daten in ein proprietäres Format zu konvertieren, ist das schon etwas bedenklich. Ich könnte damit aber leben. Immerhin muss die Datenquelle ja noch genannt werden. Wenn dadurch einer deren Nutzer dazu gebracht wird, die Daten in OSM zu verbessern, is OSM ja auch geholfen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cycleways - oftmals falsch getaggt
Simon Poole si...@poole.ch writes: Die Quelle für Leute die richtiges Englisch sprechen (hab hier grad leider nur ne kleine Version davon) sagt unter Anderem dazu: path 1 a way or track laid down for walking or made by continual treading, 2 the line along which a person or thing moves . Bei den Leuten die nicht richtiges Englisch sprechen mag das aber anders definiert sein :-) Ein Problem ist, dass viele Tags von Leuten definiert werden, deren Muttersprache nicht Englisch ist und deren Englischkenntnisse sehr verschieden sind. Außerdem ist Englisch auch nicht gleich Englisch in den verschiedenen Ecken der Welt. Daher sollte man die Bezeichnungen der Tags sowie deren Werte nicht zu eng sehen. Am Ende zählt die Dokumentation. Vielleicht sollte man Radwege als object_type=5487932 taggen. Das ist natürlich nicht ganz ernst gemeint, würde aber dazu zwingen, die Bedeutung des Tags zu dokumentieren, wenn es eine haben soll. Und auch, die Dokumentation zu lesen, wenn man wissen will, was es bedeutet. Ein paar tausend Leute sind eben schwer unter einen Hut zu bringen, so dass sie alle unter einem beschreibenden Tag das Gleiche verstehen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cycleways - oftmals falsch getaggt
Fabian Schmidt fschm...@informatik.uni-leipzig.de writes: Am 29.04.11 schrieb M∡rtin Koppenhoefer: geht es um Höflichkeit, wenn man sein Mapping den lokalen Gepflogenheiten anpassen soll? Ich empfinde es als höflich, ein einheitliches Kartenbild zu wahren, auch wenn es zu unterschiedlichem Tagging der Lausitzer und mitteldeutschen Tagebaue führt (zumal ich nicht weiß, welche noch aktiv sind).. Ich finde, man sollte daraufhin arbeiten, ein weltweit einheitliches Kartenbild zu wahren. Ich finde das Wort Gastmapper ist an sich schon ein Affront, der sich nicht mit meinem Verständnis von OSM deckt. Kannst Du Dir rückblickend vorstellen, dass lokale Mapper einen Kommentar aus der Ferne wie in http://lists.openstreetmap.de/pipermail/berlin/2011-January/000474.html als verletzend empfinden? Wenn man des Vandallismus beschuldigt wird, ist das immer verletzend. Dann ist es egal, ob der Kommentar von Nah oder Fern kommt. Der Unterschied ist nur, dass man das mit dem Mapper um die Ecke in der nächsten Kneipe ausdiskutieren kann. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3
Sebastian Hohmann m...@s-hohmann.de schrieb: Am 27.04.2011 10:45, schrieb Sven Geggus: Sebastian Hohmannm...@s-hohmann.de wrote: Das Argument hab ich nie verstanden. Was definierst du denn als Missbrauch? Und seit wann sind Firmen verpflichtet etwas zurückzugeben? Share Alike Lizenzen oder auch dei GPL sind so gebaut, dass Änderungen zwangsweise unter der selben Lizenz stehen müssen. Der Grund hierfür ist dass niemand value added Profdukte mit proprietärer Lizenz anbieten kann. Dieser Schutz ist es den PD nicht hat. Ein aktuelles Beispiel wäre Google und Mapmaker, der jetzt in USA gestartet wurde. Wären unsere Daten PD hätte Google direkt mit dem Import unserer bereits stark verbesserten Tiger basierenden Daten starten können. Trotzdem sind Firmen bei Share-Alike nunmal nicht verpflichtet generell etwas zurückzugeben, wie es häufig impliziert wird, sondern eben nur bei entsprechenden Anwendungen, die auch abgeleitete Datenbanken mit neuen Daten erstellen. Ein Produkt attraktiver zu machen, geht ja auch auf andere Weise (schnellere Server, besseres Routing, ..). Es geht doch aber gerade um die verbesserten Daten. Es kann uns ja egal sein, was irgend jemand mit den Daten macht. Nur, wenn jemand verbesserte Daten veröffentlicht, soll er das bitte unter der gleichen Lizenz machen. Und genau das wird der Grund sein, warum die ODbL auf Share-Alike bei Produced Works verzichtet. Bei OSM geht es schließlich vordergründig um die Daten. Es nützt uns relativ wenig, wenn jemand seine gerenderten Karten unter eine freie Lizenz stellt. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cycleways - oftmals falsch getaggt
Bernd Wurst be...@bwurst.org schrieb: Am 2011-04-26 13:30 schrieb Henning Scholland: Diesem Weg darf jeder benutzen. Das ist ja das geniale: highway=path alleine darf jeder nutzen, highway=path in Kombination mit somespecialfoobar=designated darf eben nur noch somespecialfoobar benutzen. Das bedeutet, um zu entscheiden ob ein hundsordinärer Radfahrer den Weg nutzen darf, muss er Tags auswerten die ihn nicht betreffen bzw. die er potenziell gar nicht kennt, weil irgend jemand ein Verkehrsmittel eingetragen hat das vielleicht auch schmaler als ein Auto ist und daher auch irgendwie in die path-Kategorie gehört. Nein, muss er nicht. Um zu entscheiden, ob er da lang darf, muss er nur noch das bicycle-Tag auswerten. Er weiß dann nur nicht, wer da eventuell außerdem noch lang darf. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kein Quellen-/Lizenzhinweis
bundesrainer o...@bundesrainer.de writes: Am 13.04.2011 15:37, schrieb Tobias Knerr: Am 13.04.2011 15:13, schrieb Alexander Matheisen: Macht sie irgendwie unglaubwürdig... Dass sie unabhängig von OSM sogar ihre eigenen Inhalte unter CC-BY-SA stellen, würde ich positiv hervorheben. Dass sie die Sache mit dem Lizenzlink hinbekommen, ist auch schon fast ein Alleinstellungsmerkmal unter Weiternutzern... Ein Vorstandsmitglied ist gleichzeitig auch bei Creative Commons Deutschland für die Öffentlichkeitsarbeit zuständig. Da darf man einen vernünftigen Umgang mit Lizenzhinweisen schon erwarten. Das mit dem fehlenden Quellenhinweis ist wohl einfach nur ein Versehen. Und da die Karte hier nur als Hintergrund für eine Grafik dient und als Karte gar nicht zu gebrauchen ist, würde ich das auch nicht so eng sehen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] alternative API-Dienste nutzen
Jan Tappenbeck o...@tappenbeck.net writes: Am 11.04.2011 21:09, schrieb Carsten Gerlach: Am Montag 11 April 2011 schrieb Jan Tappenbeck: Am 10.04.2011 19:34, schrieb Florian Gross: Note that bbox queries have a maximum of 10 square degrees. ^^ bringt auch eine Fehlermeldung bei -4 bis +4 sind 8 Degree und von 35 bis 44 sind es 9 !! 8 Grad * 9 Grad macht bei mir 72 Quadratgrad und das ist größer als 10. Oder? Gruß, Carsten Ach so ist das zu sehen - dann müßte man also Kacheln oder immer die Welt abfragen und wirklich ausschneiden. Oder man nimmt einen entsprechenden Extrakt und filtert selbst, z.B. mit osmosis. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] alternative API-Dienste nutzen
Jan Tappenbeck o...@tappenbeck.net writes: hi ! es gibt ja zwischenzeitlich jxapi und auch von mapquest eine entprechende alternativen. Bei beiden habe ich aber festgestellt das http://open.mapquestapi.com/xapi/api/0.6/way[shop=farm][bbox=4.6582031,45.0890356,16.875,55.5783447] eine Fehlermeldung (nur 10 grad auswertung zulässig) bekommen. Eine globale Auswertung http://open.mapquestapi.com/xapi/api/0.6/way[shop=farm] ist allerdings möglich - obwohl bei Mapquest bbox beschrieben. Ist mir ein Fehler unterlaufen - kann mir jemand weiterhelfen ? Es macht ja wenig Sinn und ist performancelastig wenn ich die Welt auswerte und dann nur DE mit osmosis herausfiltere. Nicht notwendigerweise. Eine Datenbankabfrage ohne bbox ist wahrscheinlich deutlich weniger aufwendig als eine mit. Ohne bbox sucht man einfach alle Objekte mit shop=farm und dann alle Knoten, die von Wegen referenziert werden, die bei der ersten Abfrage zurückgegeben wurden. Mit bbox muss man alle Knoten in der bbox suchen, dann nach allen Wegen, die einen dieser Knoten referenzieren und dann alle Relationen, die einen dieser Knoten oder Wege referenzieren. Von all diesen Objekten muss man dann nebenbei diejenigen herausfischen, die shop=farm haben. Aber vielleicht ist es ja auch nur ein Bug. ;-) Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Okay, this is just cool (Lockport, NY)
David Murn da...@incanberra.com.au writes:
Based on andrzej's email correspondence, where it was pointed out that
the relevant point in ToS is in regards to 'mass downloads or bulk feeds
of any content', I assume this means that we cant automate the process
from googles resources (such as the bing street tracer), but that
individual use is fine ('checking the odd street name is okay').
I have read that a bit differently: If you come across an odd street
name in OSM (or some random street without a name) you may check it in
StreetView. But, you may not go through an area in StreetView and
systematically add every street name you find -- automated or not.
Matthias
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Neue Nuklearkarte Deutschland
fly lowfligh...@googlemail.com writes: Am 02.04.2011 15:39, schrieb Jens Frank: Zur Standortbewertung müsste man sich natürlich noch anschauen, ob man nicht evtl in der Nähe ausländischer AKWs wäre. Frankreich stellt seine AKWs z.B. gerne in Grenznähe auf. Die Schweiz ist da auch nicht besser, wobei Leibstadt ja schon angezeigt wird. Bei der Größe der Schweiz gibt es nicht viele Orte, die _nicht_ in Grenznähe sind. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Extracting a BBOX from an osm change file
Phil! Gold phi...@pobox.com writes: * Rodolphe Quiedeville rodol...@quiedeville.org [2011-03-11 13:39 +0100]: I want to know if changes files from planet.openstreetmap.org/hourly-replicate/ are useful for a BBOX. My first idea wass to to this with osmosis, if someone give me a hint. You can't apply a bbox to a change file. Change files basically contain the IDs of changed objects and their current properties. Notably, they do not contain the old properties of the objects, so osmosis cannot tell in all cases whether an object should be considered to be in or out of the bbox. To be a bit more precise: Change files contain only changed objects but not their dependencies. That means that if someone changes a tag on a way or relation the change file will contain that way or relation but not the nodes they contain. Therefore, osmosis can not know where that way or relation is located. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bike / Pedestrian directions on the MQ Open sites
Jo winfi...@gmail.com writes: About that tag, it makes sense if there actually is a bicycle path, but when it's a street where only bicycles can go in two directions, wouldn't it make more sense to use one_way:bicycle=no? Well, you can propose to change the tagging scheme, but the cycleway=opposite tag has been used for this purpose for ages. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unsetting CT flag
On Wed, 8 Dec 2010 21:45:14 +1100, Andrew Harvey andrew.harv...@gmail.com wrote: I've decided to just ignore the CTs for now, and continue to operate under CC BY-SA. Others are doing this to, and you could too, assuming you haven't agreed to the CTs and you don't actually plan to sit around after the complete license transition. I'm yet to hear from anyone in my local community who is vocal against this practice so I'm not inclined to stop. Exactly. If you are not forced to upload under the new CTs (e.g. your account was created before they were mandatory for new users and you have not voluntary agreed to them) there is no harm in continuing to upload your data (unless you have a problem with CC-BY-SA, of course). As has been stated numerous times there will be a last CC-BY-SA planet file with all data before the data is relicensed. Your data won't be lost if you don't agree to the new CTs. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] imagery-Plugin Luftbild verschiebe
On Wed, 8 Dec 2010 11:44:57 +0100, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: Am 2. Dezember 2010 20:18 schrieb Stephan Knauss o...@stephans-server.de: Man müsste auf Serverseite irgendwie die Möglichkeit haben dem Plugin zu sagen hör mal meine Daten sind gut, schalte verschieben bitte ab. In der Theorie kann doch der Offset mit jeder einzelnen Kachel anders sein, oder? der offset ist von den Kacheln völlig unabhängig, d.h. er kann auch innerhalb derselben Kachel unterschiedlich sein. Genau. Vor allem in unebenem Gelände wenn die Bilder nicht oder nicht richtig entzerrt wurden. Schön sieht man das, wenn mal ein Schornstein oder Turm (nicht gerader der in Pisa) drauf ist. Dann sieht man, dass auf dem Bild die Spitze ein Stück neben dem Fuss ist, obwohl der Turm eigentlich senkrecht stand. Das ganze ist von der Turmhöhe sowie von der Flughöhe und seitlichem Abstand des Turmes von der Flugbahn des Fliegers, der die Bilder gemacht hat, abhängig. Bei anderen Bodenerhebungen ist der Effekt der gleiche, nur nicht so offensichtlich. Deshalb müssen die Luftbilder anhand von Höhendaten korrigiert werden. x -- Flugzeug / / / /| / | -- Turm / | X---|-- ^ | Turmspitze auf Bild Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Großes Multipolygon (50k Nodes) h ochladen
On Mon, 6 Dec 2010 08:26:46 -0800 (PST), Walter Nordmann walter.nordm...@web.de wrote: hi thomas, immer noch serbien? ok, spltte die tausende neuen ways in kleinere pakete auf und packe jeweils die passenden neuen nodes dazu. alles ids negativ aber im osm-file eindeutig. jedes file darf wieder bei -1 anfangen. und am ende noch ne relation rein (ebenfalls negativ), die die ways eines uploads in einer relation zusammen fasst. an ende stellst du die neuen teilrelationen manuell in einer super-multipoint relation zusammen. das wars ;) gruss walter also erst alle nodes, dann alle ways und dann eine relation. alles in ein file. das ganze ca 10x upload starten, in den weihnachtsurlaub fahren und nächstes jahr mit nem neuen accout weitermachen ;) ;) ;) duckweg Genau! Solche Monster hochzuladen sollte man schon gut begründen können. Ansonsten hat JOSM eine Funktion, die Daten häppchenweise hochzuladen. Im englischen JOSM heisst die Chunked Upload. Da kann man dann festlegen, wieviele Objekte per Upload JOSM hochladen soll. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Großes Multipolygon (50k Nodes) h ochladen
Walter Nordmann walter.nordm...@web.de writes: Matthias Julius wrote: Ansonsten hat JOSM eine Funktion, die Daten häppchenweise hochzuladen. Im englischen JOSM heisst die Chunked Upload. Da kann man dann festlegen, wieviele Objekte per Upload JOSM hochladen soll. das ist dann doch immer noch ein changeset und damit greifen doch dessen beschränkungen. (oder?) ich würde die daten dennoch in mehrere files aufbrechen und die dann - unter benutzung des von dir vorgeschlagenen features - hochladen. In mehrere Dateien zerteilen geht nur, wenn es keine Abhängigkeiten zwischen den Dateien gibt, do sonst die neuen IDs von der ersten Datei der zweiten nicht bekannt sind und die Objekte nochmal als neu hochgeladen werden. Um eine Grössenbeschränkung von Changesets zu umgehen, kann man auch einen Teil der Daten in JOSM selektieren und dann Auswahl hochladen. Das kann man dann so oft machen, bis der Rest in einen Changeset passt. Auf diese Art bleiben die Daten konsistent - ausser, wenn beim Upload ein Problem auftritt (Netzwerkproblem z.B., nicht Problem mit den Daten). Deshalb sollte man es mit der Grösse der einzelnen Uploads auch nicht übertreiben. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bing und SlippyMap
On Fri, 3 Dec 2010 15:47:52 +0100, UMAX974 umax...@googlemail.com wrote: Hallo, Hab gerade nach der Anleitung mein gut funktionierendes WMS (auch mit Bing) und slippymap ausgenockt und imaginary als einziges Plugin aktiviert. ^ so nu is Bing auch weg, auch in den Einstellungen und der Auswahl der diversen wms plugins ist Bing nirgends zu finden, so was mach ich nu...? Vielleicht hast Du Dir das Plugin nur eingebildet. Das heisst nämlich Imagery. ;-) Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-legal-talk] Database and its contents
adca03156...@localhost fca549be3ecf9d4cb8cb8576837ea4890a7...@zeus.cetest.local Message-ID: 90c6e47a092dece1a7770a5cb6164...@localhost X-Sender: li...@julius-net.net User-Agent: RoundCube Webmail/0.3.1 On Thu, 25 Nov 2010 17:39:46 +0100, ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl wrote: But there is no restriction to do with any work that is not protected by license or PD. In that sense any license is a restriction. No, a license cannot protect any work or restrict what one can do with the work. It can only give permissions. Of course, these permissions might have some conditions (like BY-SA). The protection comes from the law (copyright, database right, patent right, ...). What is not restricted by the law is permitted. Matthias ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] CT, section 3
On Fri, 26 Nov 2010 16:47:14 +0100, Robert Kaiser ka...@kairo.at wrote: Olaf Schmidt-Wischhöfer schrieb: There seems to be a substantial number of OSMF members who consider all data created by individuals to be community-owned, even going so far as to accuse people who refuse to accept the CT as holding our data hostage. This mindset gives me a feeling that OSMF and the OpenStreetMap community ignore the many hours that I spent for creating OpenStreetMap content. I contributed to OpenStreetMap because it is licensed under the CC-BY-SA. I would never have contributed under a license that says: All your work is now ours. You give up all control. Bugger off if you disagree. You can't reasonably have people keeping control of their contributions to 100% at all time, because contributions from all of us are so heavily entangled that it's nearly (if not completely) impossible to separate them again and determine what's owned by whom, esp. as we routinely modify database objects created and modified by random other contributors. I can't see how it would work in practice to keep control over individual contributions. Especially there so many ways how OSM objects can get disconnected from their history like delete/undelete (remember, there is no real undelete, the data gets uploaded as new again and gets new IDs), splitting (part of the object gets uploaded as new with no reference to the old version) and merging (the merged object only stays connected to the history of the one it inherits its ID from). Matthias ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-de] Frage an die Nutzer von Geofabrik-Extrakten
On Fri, 26 Nov 2010 08:24:46 +0100, Frederik Ramm frede...@remote.org wrote: Die Geofabrik-Extrakte verhalten sich also ab jetzt so: 1. alle Nodes im betreffenden Gebiet sind enthalten 2. alle Ways, die einen dieser Nodes nutzen, sind enthalten, allerdings werden sie um die Nodes gekuerzt, die ausserhalb des Gebiets liegen 3. alle Relationen, die irgendein Objekt referenzieren, das im Auszug enthalten ist, sind ebenfalls enthalten, allerdings werden sie um die Elemente gekuerzt, die nicht enthalten sind 4. alle Objekte sind wie ueblich numerisch aufsteigend sortiert. Zu 2. und 3.: Ich fände es deutlich besser, wenn Objekte in den Extrakten nicht modifiziert würden. Dann wären grenzüberschreitende Objekte eben unvollständig. Eine verarbeitende Software kann das ja relativ einfach selbst beschneiden. Unmodifizierte Objekte hätten aber den grossen Vorteil, dass sich zwei benachbarte Extrakte problemlos ohne Lücken wieder zusammenfügen lassen würden. Mein konkretes Problem: Ich wohne z.Z. in der Schweiz, meine Eltern in D und die meiner besseren Hälfte in F. Wir sind also in den drei Ländern häufig unterwegs und daher möchte ich mir eine Garmin-Karte basteln, die diese Länder enthält. Mit den Geofabrik-Extrakten ist dies so nicht möglich. Mir ist natürlich bewusst, dass es da auch andere Lösungen gibt, aber das zusammenfügen von ein paar Extrakten is deutlich bequemer als das Ausschneiden aus dem Europa-Extrakt z.B. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage an die Nutzer von Geofabrik-Extrakten
On Fri, 26 Nov 2010 01:32:45 -0800 (PST), NopMap ekkeh...@gmx.de wrote: Hi! Matthias Julius wrote: Zu 2. und 3.: Ich fände es deutlich besser, wenn Objekte in den Extrakten nicht modifiziert würden. Dann wären grenzüberschreitende Objekte eben unvollständig. Eine verarbeitende Software kann das ja relativ einfach selbst beschneiden. Unmodifizierte Objekte hätten aber den grossen Vorteil, dass sich zwei benachbarte Extrakte problemlos ohne Lücken wieder zusammenfügen lassen würden. Da muß ich Dir widersprechen. Es ist sehr gut so, daß in den Extraktne keine ungültigen Referenzen auf nicht vorhandene Objekte enthalten sind - denn die lösen in weiterverarbeitenden Tools Fehlermeldungen aus. Ist ja auch richtig so, keine Software kann einen Verweis auf etwas das nicht da ist verarbeiten. Es ist zwar schon ein paar Jahre her, aber die API hat auch mal unvollständige Wege ausgespuckt. Die meisten map-Downloads werden wohl unvollständige Relationen enthalten. Eine Software, die damit nicht umgehen kann, halte ich für buggy. Im Grenzgebiet macht es nur Sinn, das nächstgrößere Extrakt zu verwenden und den gewünschten Ausschnitt selbst dort zu extrahieren. Ein Zusammensetzen von OSM Files gibt immer Probleme durch Duplikate und Schneidartefakte. Zwei Extrakte vom gleichen Planet lassen sich auch problemlos wieder zusammensetzen - wenn die Daten nicht modifiziert worden sind. Bzw. wenn Du einen sehr ausgebufften Merge-Algorithmus dafür schreibst, kann der auch zwei halbe Ways wieder zum Original restaurieren. Aber alle anderen Tools, die nur ein Extrakt betrachten, sehen einen konsistenten Datenbestand. Das Problem ist, dass zwischen den beiden (oder mehr) Hälften eine Lücke ist. Mit den Standardprogrammen geht das dann nicht mehr. Geordnete Relationen kriegt man auch nicht so einfach wieder in die richtige Reihenfolge. Was passiert eigentlich mit Wegen, die die Grenze mehrfach kreuzen? Kriegt dann jedes Fragment eine eigene ID? Man kann ja nicht einfach nur die Knoten weglassen, die ausserhalb der Grenze liegen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage an die Nutzer von Geofabrik-Extrakten
On Fri, 26 Nov 2010 12:32:00 +0100, Frederik Ramm frede...@remote.org wrote: Hallo, On 11/26/10 11:54, Matthias Julius wrote: Was passiert eigentlich mit Wegen, die die Grenze mehrfach kreuzen? Kriegt dann jedes Fragment eine eigene ID? Man kann ja nicht einfach nur die Knoten weglassen, die ausserhalb der Grenze liegen. Doch, genau das macht Osmosis. Das fuehr dann manchmal zu ziemlich deformierten Polygonen. Das ist ja dann noch ein Grund, die Wege nicht zu verstümmeln. Wenn von einem Weg ein Knoten nicht im Extrakt enthalten ist, kann die Applikation entscheiden, wie sie sich verhalten soll. Wenn der Knoten aus dem Weg entfernt worden ist, kann die Applikation davon nichts wissen. Mit dem Nachbarextrakt zusammenfügen lässt sich das auch nicht sinnvoll. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage an die Nutzer von Geofabrik-Extrakten
On Fri, 26 Nov 2010 12:57:33 +0100, André Joost andre+jo...@nurfuerspam.de wrote: Am 26.11.10 12:42, schrieb Matthias Julius: Das ist ja dann noch ein Grund, die Wege nicht zu verstümmeln. Wenn von einem Weg ein Knoten nicht im Extrakt enthalten ist, kann die Applikation entscheiden, wie sie sich verhalten soll. Wenn der Knoten aus dem Weg entfernt worden ist, kann die Applikation davon nichts wissen. Mit dem Nachbarextrakt zusammenfügen lässt sich das auch nicht sinnvoll. Das hat aber zur Folge, dass in jedem noch so kleien Extrakt sämtliche Autobahnen, Bundesstraßen, Europastraßen, internationale Rad- und Wanderwege drin sind, weil die alle durch Sammelrelationen untereinander verknüpft sind. Das sind dann keine Extrakte mehr. Wieso? Die referenzierten Objekte, die komplett ausserhalb des Grenzpolygons liegen wären ja auch weiterhin nicht im Extrakt enthalten. Nur die Referenzen würden nicht beseitigt. M.M.n. sollten die Extrakte so gebaut werden: 1. Alle Knoten innerhalb des Grenzpolygons 2. Alle Wege, die mindestens einen Knoten aus 1. referenzieren 3. Alle Relationen, die mindestens einen Knoten aus 1., einen Weg aus 2. oder eine Relation aus 3. referenzieren Die Extrakte wären so am einfachsten zu erzeugen und am flexibelsten einzusetzen weil keine Daten modifiziert werden. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage an die Nutzer von Geofabrik-Extrakten
On Fri, 26 Nov 2010 14:32:51 +0100, Frederik Ramm frede...@remote.org wrote: Hallo Matthias, On 11/26/10 12:42, Matthias Julius wrote: Das ist ja dann noch ein Grund, die Wege nicht zu verstümmeln. Wenn von einem Weg ein Knoten nicht im Extrakt enthalten ist, kann die Applikation entscheiden, wie sie sich verhalten soll. Wenn der Knoten aus dem Weg entfernt worden ist, kann die Applikation davon nichts wissen. Mit dem Nachbarextrakt zusammenfügen lässt sich das auch nicht sinnvoll. Das Problem ist Kontinuitaet und der Mangel von Spezifikation. Anfangs kannte Osmosis nur den Modus, in dem ich es jetzt betreibe - dass nicht vorhandene Objekte auch nicht referenziert wurden. Irgendwann wurde das Verhalten umgestellt auf das, was heute der Default ist, naemlich, dass im Zweifel inkonsitente Extrakte entstehen, aber dafuer keine Objekte verstuemmelt werden. Damals wollte ich aber den Benutzern der Extrakte keine Aenderung zumuten, denn viele hatten sich darauf verlassen, konsistente Extrakte zu haben. Leider schliesst das alle Anwender aus, die sich für grenzüberschreitende Gebiete interessieren. Klar, man kann sich den nächstgrösseren Extrakt nehmen und sich das interessante Gebiet herausschneiden. Aber erstens muss man dann deutlich mehr Daten herunterladen, als man braucht, und dann ist es auch deutlich aufwendiger, sich einen Grenzpolygon zu basteln und zu pflegen als sich ein paar Extrakte auszusuchen und zusammenzuführen. Und jetzt haben wir es ja wieder gesehen; ich habe eine Aenderung geplant, die aber die Reihenfolge der Relationen im File betraefe, und es gab Leute, die damit nicht klarkommen. Wenn es jetzt eine exakte Spezifikation gaebe, in der z.B. drin steht, worauf man sich verlassen darf und worauf nicht, dann wuerde ich mich vermutlich einfach darauf zurueckziehen und sagen: Mein File erfuellt die Spezifikation, wenn Du die nicht verarbeiten kannst, Pech gehabt. Aber in Abwesenheit der Spezifikation gilt halt: never change a running system. Wenn Programmautoren sich auf Annahmen verlassen, die in keiner Spezifikation stehen, sind sie aber auch selber schuld. ;-) Ich würde sagen, das Mass der Dinge ist die API. Programme, die .osm-Dateien verarbeiten, sollten alles akzeptieren, was die API so an Daten ausspuckt. Und wenn die API z.B. keine Garantien zur Reihenfolge der Daten gibt, sollten Programme sich auch nicht darauf verlassen. Wenn Programme nur mit Geofabrik-Extrakten funktionieren, ist das ja auch ein bisschen kurzsichtig. Ich aergere mich manchmal, dass ich auf der Geofabrik-Seite nicht von vorn herein eine Zwangsregistrierung eingebaut habe. Als Benutzer finde ich sowas immer bescheuert, wenn ich mich irgendwo erst anmelden soll - deswegen hab ich das auch nie gemacht. Aber als Seitenbetreiber bzw. Download-Anbieter wuerde ich manchmal echt gern eine Rundmail an alle schicken: Ab dem 1.12. gibt es folgende Aenderungen, bitte richtet Euch schonmal drauf ein... - aber die Moeglichkeit habe ich nicht. Mittlerweile werden die Geofabrik-Extrakte (zu meinem Bedauern) mehr und mehr von End-User-Software heruntergeladen, da ist die Chance, die Leute zu erreichen, praktisch Null. Eine Zwangsregistrierung fände ich auch unangebracht. Aber eine freiwillige wäre vielleicht nicht schlecht. Am einfachsten geht das wahrscheinlich per Mailingliste, die jeder abonieren kann, der auf dem Laufenden gehalten werden will. Die Endanwender zu informieren ist eigentlich gar nicht so wichtig. Es sind ja die Programmautoren, die ihre Anwender ggf. mit Updates zu versorgen haben. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-legal-talk] Database and its contents
On Thu, 25 Nov 2010 13:56:54 +, Rob Myers r...@robmyers.org wrote: On 11/25/2010 01:33 PM, ce-test, qualified testing bv - Gert Gremmen wrote: That is turning reality upside down. The only reason for any license is to restrict any user of data/map/dbase or whatever the license is for. The licence only restricts those people who would restrict others. Specifically it restricts them from imposing further restrictions. Which means that, in total, there are fewer restrictions. A license is a grant of permissions, possibly depending on some conditions. Some licenses are more permissive than others, but in general a license can not take privileges away. For the prime example of copyright the law restricts what one can do with published works. The copyright holder may give you a license to do something with the work that is normally prohibited by the law. But they can not prevent anyone to do something with the work that is permitted by copyright law. Matthias ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-de] Lokalisierung und bessere Suche in Taginfo
On Mon, 22 Nov 2010 18:42:51 +0100, Jochen Topf joc...@remote.org wrote: Außerdem wurde die Suche komplett überarbeitet. Es wird jetzt in Keys und in Values gesucht. Dabei wird eine Prefix-Suche verwendet, d.h. max findet maxspeed, aber nicht betamax. Bestandteile eines Keys oder Values, die durch Doppelpunkt, Leerzeichen oder dergl. getrennt sind, werden einzeln gefunden. Sucht man nach etwas wie =residential (ohne Anführungs- zeichen aber mit dem Gleichheitszeichen), so werden alle values mit residential drin gefunden, gleich welcher Key. Sowas wie highway=residential geht auch. Der einzige kleine Schönheitsfehler, der mir aufgefallen ist, ist, dass Values, die bei mehreren Keys vorkommen, mehrfach in der Ergebnisliste stehen. Man kann zwar den zugehörigen Key recht einfach per Tooltip herausfinden, aber übersichtlicher wäre es, wenn die Keys in irgendeiner Form direkt in der Ergebnisliste ständen. Die Taginfo-Seiten haben eine OpenSearch-Definition, damit kann man die Suche auch einfach in seinem Browser einbauen. Beim Firefox klickt man z.B. das Icon links neben dem Suchfeld oben rechts an und wählt Add Taginfo. Hier ist anzumerken, dass damit das Firefox-eigene Suchfeld gemeint ist und nicht das von Taginfo. Viel Spass beim Ausprobieren! Danke! Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werden IDs von gelöschten Objekten wiede r vergeben?
On Tue, 23 Nov 2010 16:38:24 +0100 (CET), Fabian Schmidt fschm...@informatik.uni-leipzig.de wrote: Am 23.11.10 schrieb Jochen Topf: Die ID wird niemals neu vergeben. Auch deswegen, weil gelöschte Objekte ja noch da sind. Sie werden nur als gelöscht gekennzeichnet, aber sie sind mit allen ihren Änderungen in der Historie noch abrufbar. d.h. es kann passieren, dass eine ID an einer Stelle gelöscht und an einer ganz anderen Stelle wieder recycelt wird: Das kann eigentlich nicht passieren. Schon alleine deshalb, weil die IDs von der Datenbank mittels einer Sequenz generiert wird. D.h. sie werden fortlaufend vergeben, ohne dabei nachzusehen, ob irgendwo eine frei ist. http://www.openstreetmap.org/browse/node/4/history Ich halte das eher für ein Artefakt der Umstellung auf API 0.6 oder so. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-legal-talk] Best license for future tiles?
M∡rtin Koppenhoefer dieterdre...@gmail.com writes: 2010/11/17 Matthias Julius li...@julius-net.net: On Wed, 17 Nov 2010 18:20:39 +0100, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: Btw: isn't a rendering a derived database as well? A database of pixels? I would not regard a printed map as a database. And neither would I the electronic version of that. One could argue about a rendered vector map. I think that this distinction is nonsense, a vector map has a certain resolution just like a georeferenced bitmap has. There is no reason for a vector map to have a lower resolution than the OSM data itself. But, this is not the point. The difference to a bitmap is that a vector image contains descrete objects which someone could import directly into a database. So, one could view a vector map as a database of map objects. Each .osm file already is a vector map. Matthias ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-de] JOSM-Update bei Ubuntu
On Wed, 17 Nov 2010 09:13:04 +0100, Wolfgang wolfg...@ivkasogis.de wrote: ich oute mich hier mal: Für mein Suse gibt es das schon lange. Die OSM-Pakete werden von den Entwicklern in ein eigenes Repository geschoben, das über pin gefunden und in die normale Softwareverwaltung eingebunden werden kann. Immer wenn eine neue Version eines OSM-Programms (josm, osmosis, merkaartor, ...) stabile ist/scheint, wird sie von den Entwicklern rübergeschoben und kann vollkommen stressfrei eingebunden werden. Ich wundere mich eigentlich etwas, dass das unter Ubuntu so ein Thema ist. Es ist kein grosses Thema. Es muss nur jemand machen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grünflächen in Wohnanlagen
On Wed, 17 Nov 2010 17:08:03 +0100, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: Am 17. November 2010 16:22 schrieb Jan Tappenbeck o...@tappenbeck.net: Hi ! das geht aber immer mehr in Richtung PARK ! Gruß Jan :-) ich würde wohl landuse=residential lassen (wenn die Rasenflächen Teil der Wohnanlage sind) und leisure=garden mit einem geeigneten garden-subtag (s. Wiki) verwenden. Eine Wiese als Garten zu bezeichnen ist aber wohl doch etwas daneben. Was spricht gegen landuse=residential für das gesamte Wohngebiet und leisure=park für den Rasen falls es parkähnlich ist oder anderenfalls leisure=green, leisure=grass oder leisure=lawn auch wenn diese nicht in den Map Features stehen. Die gibt es aber schon 98x, 42x und 3x in OSM (laut Taginfo). Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pumpwerk der Entsorgung
On Tue, 16 Nov 2010 08:53:41 +0100, Andreas Labres l...@lab.at wrote: On 16.11.10 08:14, Guenther Meyer wrote: type = sewer Ich bin jetzt im Englischen auch nicht sooo fit, aber für mein Gefühl ist sewer eher das einzelne Abflussrohr, der Abwasserkanal, während das Abwasser (als Kategorie) IMO eher sewage heißt. Das ist richtig. Allerdings würde ich mich eher für wastewater entscheiden, da es man_made=wastewater_plant ja schon gibt. Man könnte das Ganze auch man_made=wastewater_pumpstation nennen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pumpwerk der Entsorgung
On Tue, 16 Nov 2010 09:20:50 +0100, Ulf Lamping ulf.lamp...@googlemail.com wrote: Am 16.11.2010 09:06, schrieb Matthias Julius: On Tue, 16 Nov 2010 08:53:41 +0100, Andreas Labresl...@lab.at wrote: On 16.11.10 08:14, Guenther Meyer wrote: type = sewer Ich bin jetzt im Englischen auch nicht sooo fit, aber für mein Gefühl ist sewer eher das einzelne Abflussrohr, der Abwasserkanal, während das Abwasser (als Kategorie) IMO eher sewage heißt. Das ist richtig. Allerdings würde ich mich eher für wastewater entscheiden, da es man_made=wastewater_plant ja schon gibt. Man könnte das Ganze auch man_made=wastewater_pumpstation nennen. Ich würde eine Pumpstation von der Art her parallel zu Pipeline sehen: http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpipeline Ob die einzelnen Subtags dort besonders schlau gemacht sind lasse ich mal dahingestellt, aber die Ähnlichkeit zwischen einer Pumpstation und einer Pipeline sind in der Realität so frappierend, das die dort verwendeten Subtags auch hier verwendet werden sollten. Also sowas wie: man_made=pump_station type=sewer OK, wenn es die Tags da schon gibt, ist das Kind ja schon in den Brunnen gefallen. Allerdings gibt es auch 25x type=sewage in OSM (type=sewer gibt es nur 24x). Das steht zwar nicht im Wiki, ist aber m.M.n. vorzuziehen. Die Wikiseite kann man ja anpassen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pumpwerk der Entsorgung
On Tue, 16 Nov 2010 16:49:36 +0100, Torsten Leistikow de_m...@gmx.de wrote: Die Frage hier ist doch mal wieder, aus welchem Blickwinkel man ein Objekt betrachtet: A) Es handelt sich hierbei grob gesagt um ein Objekt der Abwasserentsorgung. Und wenn man das genauer betrachtet, sieht man, dass es sich dabei um eine Pumpstation handelt. oder B) Es handelt sich hierbei grob gesagt um eine Pumpstation. Und wenn man sich diese genauer betrachtet, sieht man, dass diese Abwaesser pumpt. Die eine Sichtweise ist genauso gut/schlecht richtig/falsch sinnvoll/unsinnig wie die andere. Dann bietet sich vielleicht noch die Verwendung des utility-Tags an. Das gibt es ja auch schon 200x in OSM. Dann könnte man die obigen Fälle wie folgt behandeln: A) utility=sewage (oder wastewater) man_made=pumping_station oder B) man_made=pumping_station utility=sewage (oder wastewater) ;-) Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagwatch vs. tagstat
On Mon, 15 Nov 2010 10:55:57 +0100, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: Am 15. November 2010 10:22 schrieb Jochen Topf joc...@remote.org: Ich habe versucht mit der Karte, wo die Keys sind, so ein bischen die Geographie mit zu berücksichtigen. Ich will das auch noch weiter ausbauen auf Ways/Relations und auch für Values, sobald ich Zeit habe, mir zu überlegen, wie das effizient gemacht werden kann. ja, wenn bei der Suche auch Values berücksichtigt würden wäre das nochmal ein Riesenschritt und würde einem immens dabei helfen, wenn man ein bestimmtes (einem noch unbekanntes) Tag zu einem Feature sucht, für das bisher noch nichts dokumentiert ist. Bisher muss man in Taginfo schon eine grobe Ahnung haben, wo man suchen muss, und wenn es dann eine Amenity ist, muss man ggf. zig Seiten durchbrowsen, um festzustellen, dass es eben doch noch nichts gibt. Ich sehe die Value-Suche mit Abstand als den wichtigsten Featurerequest (der vermutlich auch auf Auswertungsseite am meisten Ressourcen schluckt). Was ich auch noch lästig finde, ist der Umstand, dass Listen sich ihre Sortierung und angezeigte Seite nicht merken. Wenn man z.B. einen Listeneintrag angeklickt hat und dann im Browser auf die Zurück-Taste drückt, wird die Liste wieder in ihrer Standardsortierung angezeigt und steht ganz am Anfang. Man kann sich den Eintrag natürlich auch in einem neuen Fenster/Tab anzeigen lassen, nur muss man daran auch denken. Ich fände auch besser, wenn die Suchergebnisse in Tabellenform angezeigt würden. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Update bei Ubuntu
On Mon, 15 Nov 2010 13:48:51 +0100, Jan Tappenbeck o...@tappenbeck.net wrote: Im Web habe ich unter [1] eine Anleitung gefunden, das josm-tested.jar heruntergeladen und sudo mv ./Desktop/josm-tested.jar /usr/share/java/ ausgeführt. Das Jar war danach auch vom Desktop verschwunden - aber wenn ich das alte Icon dann ausführe, dann wird immer noch die 20-Monate alte Version gestartet. Kann mir einer sagen wie man das am besten macht. Grundsätzlich würde ich das Paket der Distribution deinstallieren. Dann gibt es wenigstens keine Interferenzen. Debian hat das gegenwärtige josm-tested in unstable. Das Paket kann man von http://packages.debian.org/sid/all/josm/download herunterladen und per dpkg -i manuell installieren. Ob das aber unter Ubuntu funktioniert, kann ich Dir nicht sagen. Wie gut das Debian-Paket überhaupt funktioniert, kann ich Dir auch nicht sagen. Es gibt jedenfalls ein paar Bugs (http://bugs.debian.org/josm). Ich lade mir jedenfalls die jeweilige JOSM-Version manuell von http://josm.openstreetmap.de/download herunter und starte die dann per java -jar josm-testing.jar oder so ähnlich direkt von der Konsole. Unter Windows habe ich noch eine Einstellung im Start-Batch mit welchem ich der JAR mehr Speicher zuweisen. Vielleicht kann einer in diesem Zusammenhang mir gleich nochmal sagen wie ich dieses integriert bekommen. Hier funktioniert die gleiche Option wie unter Windows. Aus der obigen Befehlszeile wird dann sowas wie java -Xmx512M -jar josm-tested.jar. Man kann das ganze dann auch in ein Shell-Script schreiben. Dazu eine Textdatei (z.B. mit Namen josm-start) anlegen: --- #!/bin/sh java -Xmx512M -jar /pfad/zu/josm-tested.jar --- Dann sollte man die Datei als ausführbar kennzeichnen: chmod a+x josm-start Und dafür lässt sich dann auch ein Icon oder Eintrag im Menü anlegen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Update bei Ubuntu
Guido Scholz guido.sch...@bayernline.de writes: Die eigentliche josm-Version versteckt sich hier: /usr/share/josm/josm-0.0.svn3514.jar Man erkennt auch gleich welche svn-Version vorliegt. Genug der vielen Worte. Meine Variante besteht nun darin, diese alte Version durch eine neue zu ersetzen. Dazu kopiere ich die frisch heruntergeladene Datei einfach auf die alte z.B. wie folgt: sudo cp josm-tested.jar /usr/share/josm/josm-0.0.svn3514.jar Das ist es schon. Ein Vorteil dieses Vorgehens ist, dass sich das josm-Paket jederzeit ohne Spuren zu hinterlassen über das Paketsystem deinstallieren läßt. Weiterhin kann man josm über das normale Menu starten, denn der Eintrag bleibt erhalten. ... und wenn es Ubuntu in den Sinn kommen sollte, deren JOSM-Paket zu aktualisieren, wird die händisch installierte Version kurzerhand wieder überschrieben. Das könnte irgendwann mal für Überraschungen sorgen. Hat eigentlich irgend jemand mal das Debian-Paket ausprobiert? Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Förderbandbrücke
On Fri, 12 Nov 2010 11:37:26 +0100, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: Am 12. November 2010 11:16 schrieb Chris66 chris66...@gmx.de: Am 12.11.2010 10:58, schrieb Frank Martin: Ich meine für Güter, nicht für Menschen. für Güter wäre der korrekte englische Begriff man_made=conveyor_belt ggf. zusammen mit bridge=yes. sehe ich auch so. Es gibt schon ein Proposal dafür: http://wiki.openstreetmap.org/wiki/Proposed_features/Goods_conveyor analog zu bridge=xy könnte man es auch (zusätzlich) als bridge subtag sehen, wobei es ja auch Förderbänder gibt, die keine brückenartigen Konstruktionen sind. conveyor_belt != goods_conveyor Laut Taginfo gibt es: 6x man_made=conveyor 23x man_made=conveyor_belt 24x man_made=goods_conveyor Such Dir was aus! Schade, dass man bei Taginfo nicht nach values suchen kann. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-us] [OSM-dev] [Tagging] Super-relations or not
On Tue, 2 Nov 2010 01:02:37 +0800, Eugene Alvin Villar sea...@gmail.com wrote: On Tue, Nov 2, 2010 at 12:25 AM, Peter Budny pet...@gatech.edu wrote: As far as I'm concerned, the difference in what's required to tag things is minimal between these concerns. Therefore, wouldn't it make the most sense to choose whichever is programmatically the easiest and most flexible to deal with? It depends on what the you want to use route relations for. It's quite possible that different uses would demand different ways of structuring the route relation(s). I would sey they should be set up that is best for mappers to deal with. Software can be made to deal with any scheme as long as there is a consistent scheme. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Villain?
Iván Sánchez Ortega i...@sanchezortega.es writes: On Friday 14 May 2010 15:03:25 Nakor wrote: I take you to the word. Can you please help me finding out what in the software I use (JOSM) and/or my workflow is seriously wrong? Not running the Validator plugin frequently enough. It detects, warns, and helps fix duplicated nodes. And not updating the area first before running the Validator and uploading. An easy way to create duplicate objects with JOSM is to create new objects, save the layer to disk, upload to API and then close JOSM without saving the layer again (because I just saved it and didn't change anything, silly JOSM!). When loading the file again JOSM treats these objects still as new and happily uploads them again at the next opportunity. Aborted uploads can have similar effects when the data was accepted by the server but the server response did not make it back to JOSM. The reason behind all this is that the API server is assigning the IDs for new objects and returns them to the software which in turn needs to update its local data. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Villain?
Nathan Edgars II nerou...@gmail.com writes: It's not so simple. This changeset: http://www.openstreetmap.org/browse/changeset/4300452 made me a villain when I selectively undid a so-called hero's indiscriminate joining of highways to boundaries, power lines, and pipelines: http://www.openstreetmap.org/browse/changeset/4175719 . Of course it was useless, since another hero later came along and screwed it up again: http://www.openstreetmap.org/browse/changeset/4385668 (Apparently I'm now a hero - maybe I should do another unjoining so I can be on both lists.) It is probably good practice when disjoining two ways to move one node off to the side a little bit in order to not create duplicate nodes. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Street Naming Conventions
andrzej zaborowski balr...@gmail.com writes: On 9 April 2010 15:30, Matthias Julius li...@julius-net.net wrote: Val Kartchner val...@gmail.com writes: 3) Prefix, body, suffix is available from the TIGER data, but what about streets that have already been added (or corrected) by users? As we've seen, a bot won't always be able to correctly make these separations (as in the example of Southbay vs. South Bay given previously) How do we make it so that it meets the goals I've given? I would say: - assemble the name out of the tiger:name_* tags - if that matches the name tag re-assemble the name while expanding tiger:name_direction_prefix and tiger:name_direction_prefix and replace the name tag. Ok, added the check in r20882 although I'd say the script is useful for data from sources other than TIGER too. That may be. But, I would start with the easy stuff. It just requires a lot more scrutiny and special case handling if you are only parsing name tags. All I am arguing is that if you have the components separate like in the TIGER data then you should simply use them. Name suffixes in TIGER are a limited set. Who knows what 'St' at the end of a street name can possibly mean. I don't think that only the direction_prefix/suffix should be expanded, basically all name should be the way it is pronounced to avoid ambiguity. The East Doctor Martin Luther King, Junior Boulevard is an example that I think shows that the direction parts of the name are the least of the problems. On the signage the name appears as E DR MLKjr BLVD or similar. Question is how it appears in TIGER or other imported datasets. It is probably impossible to write a script that handles every possible case correctly. That's why I think the script should stick to the things that are unambiguous and leave the rest to humans. It is far better to leave a couple of cases untreated than to screw up good data. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
Val Kartchner val...@gmail.com writes: On Thu, 2010-04-08 at 12:23 -0400, Richard Welty wrote: i don't think anyone would argue with this. it's why having a bot rampage through fixing things is probably a Real Bad Idea unless it's extremely well thought out and comprehensively tested beforehand. While I didn't like what the bot was doing (at the time), What was the bot doing? I don't thing rampage is the correct word to use. That implies malice, which wasn't what was attempted. However, it did have a beneficial side effect: this topic. ;-) In the special case of TIGER data there is a tag tiger:name_type=Rd|Ct|Dr|... I would have thought it should be fairly save to reconstruct the name from the tiger:name_* tags while expanding tiger:name_type - IF the name is still the original one. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
Val Kartchner val...@gmail.com writes: 3) Prefix, body, suffix is available from the TIGER data, but what about streets that have already been added (or corrected) by users? As we've seen, a bot won't always be able to correctly make these separations (as in the example of Southbay vs. South Bay given previously) How do we make it so that it meets the goals I've given? I would say: - assemble the name out of the tiger:name_* tags - if that matches the name tag re-assemble the name while expanding tiger:name_direction_prefix and tiger:name_direction_prefix and replace the name tag. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
andrzej zaborowski balr...@gmail.com writes: On 9 April 2010 15:06, Matthias Julius li...@julius-net.net wrote: Val Kartchner val...@gmail.com writes: On Thu, 2010-04-08 at 12:23 -0400, Richard Welty wrote: i don't think anyone would argue with this. it's why having a bot rampage through fixing things is probably a Real Bad Idea unless it's extremely well thought out and comprehensively tested beforehand. While I didn't like what the bot was doing (at the time), What was the bot doing? I don't thing rampage is the correct word to use. That implies malice, which wasn't what was attempted. However, it did have a beneficial side effect: this topic. ;-) In the special case of TIGER data there is a tag tiger:name_type=Rd|Ct|Dr|... I would have thought it should be fairly save to reconstruct the name from the tiger:name_* tags while expanding tiger:name_type - IF the name is still the original one. Except for a few caveats the bot follows the TIGER documentation and expands everything listed there (taking into account the suffix/prefix requirements), it only touches name and name_1, 2 and so on, leaving alone other tags. I did a dry run on a piece of Canada and the ruleset applies pretty well there too, the streets there were from Geobase. But, I think it is probably safer to not parse the name and instead reassemble the name from the (expanded) tiger:name_* tags Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
andrzej zaborowski balr...@gmail.com writes: Hi, On 7 April 2010 07:36, Val Kartchner val...@gmail.com wrote: The Editing Standards and Conventions (http://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions;) page says: In the name tag, enter the full name as it appears on the street name signs. [...] Do not abbreviate words. Some sample ACTUAL street signs around here say 14th Street, 1400 South, A Ave, Bee Ct, Cheyenne Dr. If we expand the abbreviations, this still doesn't carry the other directional identifier. (e.g.: W 1400 S) However, if the directional identifer is added and expanded then A Ave becomes South A Avenue which really buries the most important part of the street name A. (Two areas I've mapped have single-letter street names, one A-H Ave and the other A-K Street.) Even expanding the local convention (for instance) of S 1000 E should be expanded to South 1000 East Street (according to the wiki), again burying the most important part. Using USPS abbreviations is the convention used by all commercial online mapping providers that I've seen. (i.e.: maps.google.com, maps.yahoo.com, www.bing.com/maps ) I think that OSM should adopt the same convention. What do people think? I'd like to see them as separate tags, but I'd really like the name= tag to remain consistent across the world, i.e. have an unabbreviated name in it, that can be passed to something like a text-to-speech system without having to keep a list of possible abbreviations for every language in the database. Especially names like St Park St (State Park Street) or St Tropez St (Saint Tropez Street) would be difficult to deal with. Changing from unabbreviated to abbreviated in a renderer or another tool is much easier on the other hand, with less space for ambiguity. Yes, this is exactly my view, too. It is much easier for tools to abbreviate the string than to expand it without ambiguity. Because in the latter case it has to make assumptions. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Editor without relation-support makes sense?
Tirkon tirko...@yahoo.de writes: Not supporting relations is impossible anyway; the API will not allow the deletion of a node that is part of a relation. Will this apply to the node3 in the example above as well, because the node itself is not member of the relation. It is only part of a way, which is member of the relation. Of course not. The API only rejects the deletion of objects that are referenced by another one. To delete a node that is part of a way which in turn is member of a relation does not involve the relation. The editor needs to update the way and then delete the node. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Are Yahoo street maps legal? (as JOSM WMS layer via desktopwms)
Valent Turkovic valent.turko...@gmail.com writes: Hi, I recently discovered destopwms [1] and it is a great utility that enables OSM, Yahoo and Google maps as WMS layers in JOSM. OSM layer is great because it is easier to map when can see the map at the same time. Do you know the slippymap plugin for JOSM? It does just that. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] US highway tagging and relations
Jeff Barlow j...@wb6csv.net writes: Shows how? This is not obvious to me. Are there examples somewhere? If they are not connected then are we supposed to move them around till they are? If so how does one guess where they are supposed to go? There is a sort button in the relation editor (the fifth from the top on the left hand side). With that JOSM tries to sort the relation members so that the end of one way in the list connects to one end of the next way. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Warning: Potential Flamewar] Clarifying Interstate Relations
Jeffrey Ollie j...@ocjtech.us writes: What's more annoying is that he is changing the names/refs. From what I understand the ref is supposed to be only the interstate/highway number (e.g. 90 or 80) and not I 90 (MN). And I don't like this at all. First, this seems to be different than how this is handled in many other places in the world. From what I have seen in Europe there is always the complete designation how it is found on highway shields used in the ref tag. Second, separating out the highway system requires the data consuming application to know how to piece things back together. Otherwise, a shield on a map for example with just a 25 in it is pretty limited in use. Third, I consider a reference containing just the number to be incomplete. IMHO, the ref tag should contain the complete designation of a piece of highway. This also makes it easier to search for this. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Warning: Potential Flamewar] Clarifying InterstateRelations
Mike N. nice...@att.net writes: Second, separating out the highway system requires the data consuming application to know how to piece things back together. Otherwise, a shield on a map for example with just a 25 in it is pretty limited in use. After / if a generalized shield solution is in place, a 25 placed on an 'Interstate' shield is quite descriptive. But it required every application that is to deal with US data to know about it. It avoids the need for the renderer or consumer to parse out the number. Which is quite trivial to do. Third, I consider a reference containing just the number to be incomplete. IMHO, the ref tag should contain the complete designation of a piece of highway. This also makes it easier to search for this. To search, just search for both the network and route tags. It's just as though the information was placed in separate database columns. Which makes it much more complicated if the application used for searching does not support the schema. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Warning: Potential Flamewar] Clarifying Interstate Relations
Jeffrey Ollie j...@ocjtech.us writes: On Mon, Feb 8, 2010 at 1:13 PM, Matthias Julius li...@julius-net.net wrote: Jeffrey Ollie j...@ocjtech.us writes: What's more annoying is that he is changing the names/refs. From what I understand the ref is supposed to be only the interstate/highway number (e.g. 90 or 80) and not I 90 (MN). And I don't like this at all. First, this seems to be different than how this is handled in many other places in the world. From what I have seen in Europe there is always the complete designation how it is found on highway shields used in the ref tag. I don't know if you have travelled much in the US and I've never been to Europe, but US road signs are pretty minimal: http://en.wikipedia.org/wiki/File:I-80.svg http://en.wikipedia.org/wiki/File:US_69.svg http://en.wikipedia.org/wiki/File:Iowa_3.svg The color and shape of the sign is used to distinguish different types of routes. On the shields, yes. But everyone calls 'I 75' just that and not 'the highway 75 on a blue shield'. Second, separating out the highway system requires the data consuming application to know how to piece things back together. Otherwise, a shield on a map for example with just a 25 in it is pretty limited in use. Again, the color and shape of the shield is used to distinguish different routes So if a renderer puts the correct shield on a highway that is certainly helpful. But, if it does not know about the particular tagging schema I would prefer that it puts 'I 25' on ther instead of just '25'. My point is that the ref tag should contain the complete reference to the object and not require the consideration of another tag. Third, I consider a reference containing just the number to be incomplete. IMHO, the ref tag should contain the complete designation of a piece of highway. This also makes it easier to search for this. That's why I set the name tag on the relation to something a little more descriptive. IMHO it is wrong to set the name tag if the highway does not really have a name. Obviously, this scheme works only in the US, which is why the network tag is used to distinguish US routes from those in other countries. The network tag is certainly useful to make it easier to distinguish a German 'A 4' from a British 'A 4' for example. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of highway=tertiary
Greg Troxel g...@ir.bbn.com writes: Stellan Lagerstrom lagerst...@blindsight.com writes: We have a user (mk408) who seems intent on turning 3/4 of all residential streets in the bay area into tertiary. This seems excessive to me. Most of these are just residential streets, not thoroughfares, etc. Views? Here's one changeset: http://www.openstreetmap.org/browse/changeset/3519089 I think tertiary is way overused. Starting with the notion that highway=secondary should be a state highway, tertiary should be a significant road that people use to get to a state highway, or at least a link between population centers of thousands of people. Other main roads within a city would then be unclassified. Not every secondary highway needs to be a state highway. I would tag roads that have more than just local relevance as tertiary. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Marking closed bridges
Richard Welty rwe...@averillpark.net writes: On 12/3/09 11:27 PM, Richard Welty wrote: On 12/3/09 11:00 PM, David Fawcett wrote: I agree that it would be good to have a standard answer. I am thinking that the tag should be used for both symbology and connectivity. i'm going to try out the suggested access=no/description=blahblahblah method see what i think about it. and now that i've seen it, the mapnik rendering is not distinguishable from access=private on the other hand, we don't tag to get a specific rendering effect from an existing renderer. Exactly! Don't tag for the renderer! maybe an additional term on access (access=closed), so that some future renderer will be able to distinguish the different reasons for restricted access. If the public does not have access at all then access=no is the appropriate tag, IMO. If you want to indicate the reason that should go into a separate tag. I don't think it is a good idea to invent a new access tag for every nuance of access restriction. No application can keep up with all those. If you want access=no to be rendered differently from access=private you can try to convince the people in charge of the rendering styles to do that. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What's causing rendering artifacts in the Southeast?
David ``Smith'' vidthe...@gmail.com writes: On Fri, Nov 27, 2009 at 2:18 AM, Dale Puch dale.p...@gmail.com wrote: It sounds like t...@home needs to trim data at the tile border, and then close open ways along the border of the tile... Just my uneducated opinion. Let's say you have a tile with two ways crossing it, and they don't intersect in the tile. Both of these ways are outer members of the same multipolygon relation, and they don't share any nodes. There's no way to determine whether to color in the space between the two ways, versus the rest of the tile except for that space, unless the renderer knows whether the ways wrap around the polygon clockwise or counterclockwise. One might think that it's safe to assume (as with coastlines) the answer is clockwise, but when multipolygons are used to map adjacent features with shared ways, that condition cannot be true for both/all multipolygon relations; so that assumption must be thrown out. In order to paint the polygon correctly, the entire polygon must be known, which means loading the entire multipolygon relation*. Well, it would be fairly easy if the ways in a multipolygon were required to be ordered. Then, when there is a gap a renderer could just connect the ways. At least this would work in most cases. It doesn't work when the area is being inverted or becomes self-intersecting when you do that. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What's causing rendering artifacts in the Southeast?
Dale Puch dale.p...@gmail.com writes: Oops I spoke too soon. There is a relation. http://www.openstreetmap.org/browse/relation/304245 I still think this is the probable source of the problem though. Perhaps someone with more experience with relations could take a look? I don't know all the details in how osmarender deals with relations, but, I think this is caused because the relation does not have any tags (besides type=multipolygon). I have changed that for one of them (304245). We'll see whether that makes a difference. This is the recommended way of tagging anyway. When a relation is used to form a feature like a riverbank the tags should go onto the relation and be removed from the member ways. Besides, this relation is a chore to work with because it has 365 members. I would say it should be split where tributaries enter the main river. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER considered harmful
David Lynch djly...@gmail.com writes: Agreed. I can understand not wanting to abbreviate words that don't have a standard abbreviation, but the USPS is the de-facto arbiter of how addresses (and therefore street names) are written in the United States, and they have a well-defined list of which words are abbreviated and the abbreviations for those words. Any decent namefinder/geocoder should be able to handle the idea that 100 W 6th St and 100 West 6th Street both refer to the same address, and a really good one should also know that 100 West Sixth St and 100 W 6 would also be at the same location. While this is true I think there is benefit for sticking with one version or the other within OSM. And since Street names usually are not abbreviated outside the US and the abbreviations might not be as intuitive for a non-english speaker I believe it would be better if they were spelled out completely. IMHO it is unfortunate this was not done during the TIGER import. It would have been easy enough. If some renderer considers the long names as waste of space it can abbreviate them. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Non-Integer addresses
Greg Williamson gwilliamso...@yahoo.com writes: Just out of curiosity, how do our European companeros deal with things like 2-Bis ? Most of the addresses I have seen in the US with letters tend to be campuses and business parks as opposed to street addresses. A legit address in France -- #2 rear would be my rough translation. I just would not assume that an address is numerical. There are house numbers in Germany like 25a, 25b, 25c, ... or even 14 ½. They just are what they are. This happens when a lot is divided up. And we don't have 5-digit house numbers. Typically they are consecutive with even numbers on one side and odd numbers on the other. The above are the alway present exceptions to the rule. And of course there are other numbering schemes. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Super Wal-Mart Tag
Randy rwtnospam-new...@yahoo.com writes: Matthias Julius wrote: Randy rwtnospam-new...@yahoo.com writes: Dale Puch wrote: Would it be improper to tag the true Wal-Mart services to the building way, (either using semicolons or shop_n and amenity_n, and the partnered services (McDonald's, etc.) as separate nodes in the building, and related with is-in? I consider numbered tags to be messy. Nodes inside the building is not better unless you are really producing a map of the building's internals. I would use relations for this purpose, e.g. one relation per shop. Matthias I guess I still don't understand all there is to know about relations. I thought you had to have a map entry such as a node or way to relate, in a relation. Back to the wiki for me. Yes, I would create a relation for each thing in the building having the building itself (area, node or relation) as the only member. That way the different shops (or banks, law offices, dentists, ...) in the building can be independant objects and reference the building. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Super Wal-Mart Tag
Randy rwtnospam-new...@yahoo.com writes: Dale Puch wrote: For the same reason as doing nodes at a mall or similar. To know the stores/services available, not just the type of stuff that is usually there. If your tagging fast food, why would you not tag the McDonalds in the super walmart as well? Or the bank ect. As for the walmart services themselves, that can be one node, but with the seprate services listed in tags. Dale Would it be improper to tag the true Wal-Mart services to the building way, (either using semicolons or shop_n and amenity_n, and the partnered services (McDonald's, etc.) as separate nodes in the building, and related with is-in? I consider numbered tags to be messy. Nodes inside the building is not better unless you are really producing a map of the building's internals. I would use relations for this purpose, e.g. one relation per shop. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] License plan
Richard Fairhurst rich...@systemed.net writes: 80n wrote: What percentage of data would other people feel willing to see sacrificed in order to move forward with the new license? I'd be interested to see this related to our userbase and editing stats. If (say) we lose 5%, how many months - at current rates of growth - does it take us to get back to the previous level? It is not that simple. What if those 5% is half of South Africa? You certainly can not interpolate overall OSM growth to re-surveying South Africa. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] oneway yes or true
Celso González ce...@mitago.net writes: I dont understand the -1 or reserved value, what that means? one way yes/true/1 but in the opposite direction of the way? Exactly. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Adding architect names to buildings
Elena of Valhalla elena.valha...@gmail.com writes: On Wed, Feb 18, 2009 at 8:48 PM, Matthias Julius li...@julius-net.net wrote: You could create an architect relation and have the buildings be members of that. that looks like a category, not a relation: I was under the impression that this use of relations was discouraged. What is the definition of a category here? I would call a category something like buildings that are 29 strories tall. An architect I would call an (abstract) object that can have other attributes as well like a birthdate, an email address and so on. (Whether all this belongs into OSM is another debate). Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Adding architect names to buildings
Jonathan Bennett openstreet...@jonno.cix.co.uk writes: Matthias Julius wrote: What is the definition of a category here? I would call a category something like buildings that are 29 strories tall. An architect I would call an (abstract) object that can have other attributes as well like a birthdate, an email address and so on. (Whether all this belongs into OSM is another debate). It may well be an abstract object, but it's not a geographical one so it doesn't belong in OSM. Relations are a way of linking one geographical feature to another for some geographical reason -- part of the same long-distance route, or opposite banks of a waterway for example. In this case there's no geographical link between two buildings from the same architect -- you could just as easily say that all buildings belonging to one company should be part of a relation, but that too would essentially be categorisation. This is all true and after rereading http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories I agree that the architect issue is a category in that definition. I just prefer to explicitly link objects together over duplication of data. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Adding architect names to buildings
Jonathan Bennett openstreet...@jonno.cix.co.uk writes: Matthias Julius wrote: I just prefer to explicitly link objects together over duplication of data. As long as the buildings are tagged consistently, having the tag is probably enough -- you can then use XAPI to query the DB for all buildings by a particular architect. IF they are tagged consistently. This is exactly the point. Especially with names of persons there might be several different ways to spell them which all might be correct, for example: Hundertwasser Friedensreich Hundertwasser Hundertwasser, Friedensreich F. Hundertwasser Hundertwasser, F. There are more variations possible when there are middle names involved. Additionally there are any number of mis-spellings possible. With names from foreign languages this is not even that impossible. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] National Forest Boundaries
Karl Newman siliconfi...@gmail.com writes: On Thu, Feb 19, 2009 at 8:21 AM, Theodore Book tb...@libero.it wrote: I have put the various proposals on the wiki at: http://wiki.openstreetmap.org/wiki/US_Forest_Service_Data It seems like the landuse=forest tag has a fair amount of consensus, but that we are not yet sure how to tag the fact that it is a national forest, and not just any forest. Especially since there may be large swathes within the national forest boundary that are devoid of trees... There is also a distinction between landuse=forest and natural=wood. But analogous to boundary=national_park there could be boundary=national_forest. And then one would need to extend this to state parks and forests as well as metro parks and who knows what kind of administrations manage some pieces of land. So maybe this should be boundary=park,admin_level=1 for national parks and admin_level=2 for state parks and so on. The possibilities are endless ... Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Large OSM globe style images
Inge Wallin i...@lysator.liu.se writes: Hi, one of the Marble developers here... I noticed that Marble shows the map right up to the poles. These are not covered by Mercator maps. So I suspect Marble stretches the map a little bit leading to some inaccuracies like water reaching almost directly up to the south pole. It would be more accurate if Marble did not stretch the map and instead allowed a fill color or image to be specified for each pole. Or is this already possible? Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Adding architect names to buildings
Robert (Jamie) Munro rjmu...@arjam.net writes: Frankie Roberto wrote: Looking through Tagwatch I noticed that both artist=* and artist_name=* have been used (presumably for public sculptures and art installation), and I did wonder whether architect_name=* would be better. It seems that artist_name=* matches old_name=* better, but on the other hand it's not particularly ambiguous having artist=* or architect=*. Why should it match old_name? Your not describing a name of the object, you are referencing the designer of the object. Unless you want architect_name, architect_address, architect_date_of_birth, architect_..., it seems pointless. Is the architect an attribute of the building or is the building an attribute of the architect? You could create an architect relation and have the buildings be members of that. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Openstreetbugs source code
Ævar Arnfjörð Bjarmason ava...@gmail.com writes: On Thu, Feb 19, 2009 at 1:14 AM, Kyle Gordon k...@lodge.glasgownet.com wrote: I hope I'm not alone in saying Thank You! :-D OSB is a wonderful resource that many of us couldn't live without. I know a few people were sceptical due to the licensing, but hopefully now they will be quiet. Yes it's useful, but I don't see how this addresses the problems of OSB being closed. Is this not a third party implementation of the OSB JS interface which is not running on the main OSB site, and is the OSB bug DB not still closed with no dumps available? But now, since the code is available, someone could set it up as bugs.openstreetmap.org or so and integrate it with the OSM main site. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Large OSM globe style images
Inge Wallin i...@lysator.liu.se writes: On Wednesday 18 February 2009 20:43:35 Matthias Julius wrote: Inge Wallin i...@lysator.liu.se writes: Hi, one of the Marble developers here... I noticed that Marble shows the map right up to the poles. These are not covered by Mercator maps. So I suspect Marble stretches the map a little bit leading to some inaccuracies like water reaching almost directly up to the south pole. It would be more accurate if Marble did not stretch the map and instead allowed a fill color or image to be specified for each pole. Or is this already possible? Good point! I'll have to check what actually happens. Can you register this on bugs.kde.org as well? Actually, after looking at the south pole again a little more carefully it seems more like Marble is projecting the pixels at the edge of the tiles towards the pole. At least this is not completely unreasonable. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] News blog link - to blogs.openstreetmap.org?
Lester Caine les...@lsces.co.uk writes: Andy Robinson (blackadder-lists) wrote: So, we have a pile of good intentioned legacy here. OGD carries posts on all sorts of open geo data stuff in the early days (Aug 2004) including the most important one http://www.opengeodata.org/?p=2 relating to OSM. Over time Steve and the others he handed out access to have posted principally about OSM but I'd argue it's never been the official OSM blog, it was just that it was the only blog where official stuff re OSM ended up. Should OSM have a separate blog, probably Blog or announcements list? I'd vote for the latter. Or both and a gateway in between. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM on The Reg
Claudius Henrichs claudiu...@gmx.de writes: Am 11.02.2009 13:18, Gert Gremmen: Kenneth: does *any* mapping app have an option like 'add road'? Do you know any mapping application accessible for everyone having internet ??? *cough* http://www.google.com/mapmaker *cough* And the thing is that Mapmaker is probably known to more people than OSM expectations of beginners will be for our editor to work just the same than Mapmaker. And if Mapmaker has an Add Road button (don't know it myself) people expect one here, too. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM on The Reg
Someoneelse li...@mail.atownsend.org.uk writes: Maybe something more akin to openstreetbugs plus a simple guided way to add one feature at a time should be integrated into OSM, but I wouldn't use GMM as an example except of what not to do! We certainly should not try to emulate their bugs. But, are there any elements in their user interface that are nice to have (if they work right)? Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
Frederik Ramm frede...@remote.org writes: There being multiple relations for the same walking route is something that happens every day, not because of the size limit but because someone working on a local bit of the route might not be aware of someone else working on another local bit until they meet. It is actually *easier* to then combine the parts in a super relation than to move all the members from one part-relation to the other. I'm pretty sure we'll soon have good tools to work with that kind of thing. And anyway, if the super-relation is ignored and someone just sees the smaller parts of the walking route, that's not a big loss is it? What I don't like here is that this leads to duplication of data. Super-relations are fine, but IMHO tags should be moved to the super-relation. And then it would be a big loss if a renderer doesn't know how to deal with it. What is an application actually supposed to do when the tagging of of a relation contradicts the tagging of its members? For example: a super-relation with ref=E50 with a member-relation with ref=E52 which has a way tagged with ref=E58 Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
Frederik Ramm frede...@remote.org writes: Hi, Matthias Julius wrote: What I don't like here is that this leads to duplication of data. Super-relations are fine, but IMHO tags should be moved to the super-relation. They should, but I would postpone that until later. Yes. I just like to bring this up once in a while to nudge people into thinking in that direction. ;-) The same is true with today's superways - tags should really be moved from the way into the relation but we can wait with that until everyone knows how to handle a superway. I'm just afraid you can wait forever here. I am not saying that people are too stupid to grasp the concept. It is more a matter of motivation to deal with the issue. I think a prerequisite is support in the main renderers. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-dev] donating read-only api-mirrors
Milenko mile...@king-nerd.com writes: As far as I know, the ROMA servers return data as close as possible to the main API. They should be no more than 3-5 minutes behind the main API. Please correct me if I'm wrong (and I very well could be!). But they still don't implement the whole API. They only implement the map call. That's why they are called ROMA (Read Only Map Api). The data is supposed to be complete. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Key:smoothness
Dave Stubbs osm.l...@randomjunk.co.uk writes: 2009/2/2 Richard Fairhurst rich...@systemed.net: Ulf Lamping wrote: Yes, if it would use descriptive terms it might solve some problems. But if you think of a better solution it gets really difficult to find better terms thats aimed towards something. smoothness:vehicle would make sense to me. But, you know, water under the bridge and all that. suitability_wheeled_vehicle would be even better. Suitability sounds a bit more fitting than smoothness. And one could put the type of vehicle into the value like 'suitability=horse:good;mountainbike:bad;racebike:impossible' or something like that. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] when do 12 TAH tiles render?
Vikas Yadav vikas.ya...@threebrix.com writes: Just a casual query about what is the schedule to render TAH tiles below z12. I had changed many things in North India maps and those zoom levels still show tiles. They get stitched togetcher from z12 tiles after the rendering of a z12 tiles was requested, rendered and uploaded. If you render and upload tiles before they get auto-requested the server won't stitch lowzoom tiles. The auto-requester only considers changes to nodes, BTW. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Handling of towns with different or alternative names
Simon Ward si...@bleah.co.uk writes: On Tue, Jan 27, 2009 at 02:50:37PM -0500, Russ Nelson wrote: On Jan 27, 2009, at 2:08 PM, Manfred Podzkiewitz wrote: Hello, i have a question about the handling of unoffical, or ethnic, or historic names of towns and villages. The TIGER import in the USA uses name_1 for alternate names. Perhaps we should view all tags starting with name as potential names? That points to using nameEN for the English name of a city, and nameDE for the German name of the same city, etc. Or should that be name:EN and name:DE? These already exist, see Key:name[1]. This doesn’t account for multiple names in the same language, though. I can also imagine a place having several old names over time, while old_name=* really only allows for one. IMHO there really needs to be a well defined mechanism that allows a tag to have multiple values. To invent new keys like old_name_1 and old_name_2 is certainly not optimal. The FAQ has the recommendation of separating multiple values with a ';' and to enter a semicolon that is part of the data as ';;'. That's actually error prone if someone enters a semicolon who doesn't know about the rule. I think that should better be reversed or '\;' be used as separator because this is much less likely to appear in regular data. Of course it is also possible to use relations. But, for tags that simply add a property to an object (like old_name) this is overkill. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Can not remove a way from a relation
Shaun McDonald sh...@shaunmcdonald.me.uk writes: On 27 Jan 2009, at 20:46, Erik Lundin wrote: Hi, I had a similar problem earlier this month. The correspondence can be found in the mail archives: http://lists.openstreetmap.org/pipermail/talk/2009-January/thread.html#33157 The problem is that JOSM gets an error while uploading a relation that references a non-existent way. I wrote a little perl script to find relations referencing non-existent ways or ways referencing non- existent nodes. Using the script I found that the relation (21359) contains a reference to way 8135282, which was deleted on January 5th (http://www.openstreetmap.org/browse/way/8135282/history). I tried to remove the way from the relation, but get the same error while uploading. There could be another way that has been deleted, or there is a node that is reference by a way that is missing. Does the API verify the integrety of a way that is referenced in a relation and that itself is not being uploaded? Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Handling of towns with different or alternative names
Simon Ward si...@bleah.co.uk writes: On Tue, Jan 27, 2009 at 04:36:08PM -0500, Matthias Julius wrote: That's actually error prone if someone enters a semicolon who doesn't know about the rule. I think that should better be reversed or '\;' be used as separator because this is much less likely to appear in regular data. Almost any character could appear in regular data, unless it’s quite a special character—say, rather appropriately, the unit separator (US, ASCII 0x1f). The problem then is entering the special character. While this is true, a key sequence like '\;' or '\\' should rarely be seen in nature. At least it should be a lot less likely than a single ';'. To be on the safe side we can use '/|\|/|\|/|\' or similar. ;-) Ultimately the user should not have to care what, or if a, separator is used, and they would be presented with multiple values as appropriate for the interface they are using. This is true, but AFAIK no editor supports that, yet. Until then it needs to be done manually. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapping driveways
Ulf Lamping ulf.lamp...@googlemail.com writes: First of all, you should NEVER remove anything from the database, unless you have made certain by your own eye that the object in question is an error and not existing in reality! Even than take care not to remove anything marked as abandoned or alike, that marks this object was once here and the info is kept for historical reasons. Yes, renderers and other applications can then choose whether they want to use that information or not. Here in germany we are simply not asking if something should be included! People in densely mapped areas are starting to map single trees and litter bins - not all of us doing so, but that's not the point here. How this should be tagged depends on what's on the ground. Please have a look at: http://wiki.openstreetmap.org/index.php/Map_Features It indicates to use highway=service together with service=driveway. Funnily enough, I don't have a clear understanding what a driveway actually is, seems to be an american english specific term? It's typically a piece of pavement that connects the road with peoples garage door. Of course, the pavement and the garage are optional. In German I would probably say Grundstückseinfahrt. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] When is a bridge not a bridge?
Kenneth Gonsalves law...@au-kbc.org writes: On Friday 23 Jan 2009 6:00:08 pm Sven Rautenberg wrote: if the way is layer=0 and the bridge is layer=0 too (the crossing way under is layer=-1, digged) then the bridge has no ramps. Something with negative layer has to be a tunnel. Bridges are useless if there is a tunnel. Do not tag bridges as layer=0 just because there are no ramps. The layer tag is to help a renderer put the ways in the right visual order - not to indicate whether or not a way is elevated or not. Do not tag ways as layer=-1 just because they are below the general earth surface (such as rivers). this is important - only underground rivers should be given a -1 layer tag Yes, it has been pointed out many times that layers are relative only and have nothing to do with elevation. They describe whether some object is directly above another and not whether it is higher than another one nearby. Generally, I regard the earth's surface -- natural or not -- as layer=0. That means that a bridge which is completely level with the surrounding area is still layer=1 (at least) because it is above the ground. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Can not remove a way from a relation
Gerda og Carsten gerdaogcars...@toensberg.dk writes: I am unable to remove way http://www.openstreetmap.org/browse/way/4596756 from the relation http://www.openstreetmap.org/browse/relation/21359 I am thus also unable to delete way 4596756 which is overlapping another way also beeing part of the relation. I am using JOSM and get en error when I try to upload the relation after having taken way out of the relation. It might be helpful to know what the error is. The console output of JOSM might be interesting, too. I can see that this relation has more than thousand ways, and I think this could be the problem. You get the error after a fresh download of the relation? Such a huge relation has a large potential for conflicting edits because many people might want to edit it at the same time. However, I can't really think of why uploading a new version of a relation could create a conflict for the API. Maybe JOSM runs into a timeout with a large object like this when the server is under load. Again, what is the error? Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] When is a bridge not a bridge?
Marc Schütz schue...@gmx.net writes: (Forwarding to list) Am Friday 23 January 2009 17:28:17 schrieben Sie: As I understood the text of the wiki when I first started, layer 0 is the general level of the terrain, so levels 1, 2, 3, 4, 5 are above the ground on successively higher bridges, and -1, -2, -3, -4, and -5 in successively deeper trenches. Indeed, that's what the wiki page says. Unfortunately I cannot find the place where the discussion took place when the feature was introduced (probably before today's standardization process); I'm pretty sure that this was not intentional. One could argue that because the default is layer=0, the natural surface would be in this layer. However, we do not model the natural surface, so this seems to be a completely arbitrary limitation. Lacking a definition for natural surface, there isn't even an application where this information could be utilized. The layer tag is just the way to tell applications about the vertical ordering of objects. It is irrelevant for objects that don't overlap. And the absolute number doesn't matter as long as the higher object has a higher number. A somewhat special case are objects that are next to each other that overlap in map renderings because they are rendered wider than reality, like a road next to a railway. Then it should be up to the renderer to decide how to solve that. Everything else is just a matter of convention. I think it produces the least amount of surprises if layer tags are applied to the smaller feature (like the bridge instead of the river) to avoid effects on more distant intersections. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
