[OSM-talk] JOSM: Import audio with version newer than 1150
Hello, After I updated JOSM to latest version (v 1178) I started to have problem with audio. When I import audio and start playing, the play head goes to the end of the track. If I pause playing and try to drag the play head to another place on the track and synchronize, I always get the message 'Audio synchronized at point 0' (no matter which point I choose on the track). As soon as I resume playing, the play head jumps to the end of the track. I tried all JOSM versions available on download page, and the last working version is v 1150. Versions from 1171 and up show this problem. This happens on Windows. Any ideas? Best regards, Alberto ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - RFC - Advanced footway and cycleway
http://wiki.openstreetmap.org/wiki/Proposed_features/Advanced_footway_and_cycleway ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] JOSM: Import audio with version newer than 1150
Hello, I suspect some plugins have recently been compiled and published for a JOSM version which exists only in the SVN. In other words, someone should refresh the current 'josm-latest.jar'. The alternative is getting the source code from the svn and compiling it yourself. This happened with the wmsplugin. regards, Lucas De: talk-boun...@openstreetmap.org en nombre de Alberto Nogaro Enviado el: vie 26/12/2008 16:36 Para: talk@openstreetmap.org Asunto: [OSM-talk] JOSM: Import audio with version newer than 1150 Hello, After I updated JOSM to latest version (v 1178) I started to have problem with audio. When I import audio and start playing, the play head goes to the end of the track. If I pause playing and try to drag the play head to another place on the track and synchronize, I always get the message 'Audio synchronized at point 0' (no matter which point I choose on the track). As soon as I resume playing, the play head jumps to the end of the track. I tried all JOSM versions available on download page, and the last working version is v 1150. Versions from 1171 and up show this problem. This happens on Windows. Any ideas? Best regards, Alberto ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Installation on local PC
Hello! My aim is to set up Openstreetmap on my local PC. I've reached this step: http://wiki.openstreetmap.org/wiki/Mapnik#Rendering_with_Mapnik and i can't execute from Cygwin: $ source ./set-mapnik-env $ ./customize-mapnik-map $MAPNIK_MAP_FILE Here is the error message: Execution of PostgresSQL by a user with administrative permissions is not permitted. The server must be started under an unprivileged user ID to prevent possible system security compromises. See the documentation for more information how to properly start the server Any idea how to solve this administrative permissions problem? Regards -- View this message in context: http://www.nabble.com/Installation-on-local-PC-tp21103371p21177550.html Sent from the OpenStreetMap - General mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Installation on local PC
On Fri, Dec 26, 2008 at 6:59 PM, Tokajac imre_to...@hotmail.com wrote: Here is the error message: Execution of PostgresSQL by a user with administrative permissions is not permitted. The server must be started under an unprivileged user ID to prevent possible system security compromises. See the documentation for more information how to properly start the server Any idea how to solve this administrative permissions problem? Have you tried to do as the error message suggests and consulted the PostgreSQL documentation on the proper way to start the server? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Problem adding images to Flickr OSM pool
I am having problems with adding Flickr images to the OpenStreetMap pool (and also to the ItoMedia pools) from a new user we have created. I have upload some (pretty!) images onto Flickr using the new user 'ItoWorld'. I have tried to add them to the OpenStreetMap pool however these images do not appear in these pools unless I am signed in (either as ItoWorld or as PeterIto). I also have this problem with the ItoMedia pool and it is not just me. Avar is listed at the bottom of ItoMedia pool as contributing 2 images (http://www.flickr.com/groups/itomedia/pool/) however I can only see these images on the pool if I am signed in (as with the OSM pool). Strangely osde8info and PeterIto's images can been seen in ItoMedia when one is not signed in. I have checked the settings for the ItoMedia pool and also for the users PeterIto and ItoWorld and can't see anything wrong. I can't of course check the settings for the OSM pool. Can other people see ItoWorld's and Avar's images in the ItoMedia pool when they are signed in (but not see them when they are not)? Can other people see ItoWorld's images in OpenStreetMap pool only when they are signed in? Has anyone else experienced this problem elsewhere? Thanks, Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] golf question
Hi, I am developing what in golfing terms is known as a stroke saver. This is a map of a golf course where the distances between various points are marked. The points may be significant rocks, trees, palm trees, yardage markers, sprinkler heads ... since these tags are specific to golf, I would not expect the regular renderers to ever render these. However the tags would be in the OSM database and rendered by a dedicated server. I would like some feedback on how to make these tags. I was thinking of something like this: golf=marker marker=tree/palm/rock/yardage/sprinkler etc description=some description Using this I expect to generate an svg image on which the lines can be drawn to show distances from given markers to other markers. Or could these lines be ways? golf=yardage distance=n any comments would be appreciated. -- regards Kenneth Gonsalves Associate NRC-FOSS http://nrcfosshelpline.in/web/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Fietspaden kots
Het valt mij vaak op dat mensen ten onrechte een fietspad naast een weg tekenen, terwijl die weg al de tag cycleway=track etc hebben. Bijna net zo vaak valt het mij op dat die mensen het begin en eind van dat fietspad helemaal niet hebben vastgezet aan bestaande wegen. Nu is ook mijn dorp het slachtoffer ;) geworden van deze fietspaden kots. Wat te doen? Verwijderen en de editor inlichten? Is dit nieuwe policy? http://www.openstreetmap.org/?lat=52.11522lon=4.90777zoom=17layers=B000FTF http://www.openstreetmap.org/?lat=52.081477lon=4.868685zoom=18layers=B000FTF -- Matthijs ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietspaden kots
Matthijs Benschop wrote: Het valt mij vaak op dat mensen ten onrechte een fietspad naast een weg tekenen, terwijl die weg al de tag cycleway=track etc hebben. Het lijkt me wenselijk dat een cycle way die naast een weg loopt niet in de zelfde weg is opgenomen. Analoog aan als een weg uit twee banen met een midden berm bestaat je hem als twee 'one ways' tekent. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietspaden kots
Stefan de Konink wrote: Matthijs Benschop wrote: Het valt mij vaak op dat mensen ten onrechte een fietspad naast een weg tekenen, terwijl die weg al de tag cycleway=track etc hebben. Het lijkt me wenselijk dat een cycle way die naast een weg loopt niet in de zelfde weg is opgenomen. Analoog aan als een weg uit twee banen met een midden berm bestaat je hem als twee 'one ways' tekent. Bedoel je dat je die dan apart moet taggen? Dat zou betekenen dat je naast zo'n beetje elke provinciale weg een fietspad moet gaan tekenen. Daar teken ;) ik toch niet voor. M.i. is een fietspad dat langs een weg loopt onderdeel van de weg, behalve als het een duidelijk andere loop heeft. Bijvoorbeeld het fietspad ten noorden van de Metamorfosenalle wat afbuigt naar de Oegsgeeststraat hier: http://www.openstreetmap.org/?lat=51.955lon=5.853zoom=18layers=B000FTF Het fietspad ten zuiden is dan een discussiepunt. Ten oosten zou ik hem apart leggen (vooral vanwege de onderdoorgang bij het kruispunt), ten westen (richting Marasingel) zou ik hem weer verwijderen. (stukje weg heb ik daar getagd, het fietspad lag er al) Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietspaden kots
On Friday 26 December 2008, Matthijs Benschop wrote: Het valt mij vaak op dat mensen ten onrechte een fietspad naast een weg tekenen, terwijl die weg al de tag cycleway=track etc hebben. (Eens met Stefan.) Bijna net zo vaak valt het mij op dat die mensen het begin en eind van dat fietspad helemaal niet hebben vastgezet aan bestaande wegen. Nu is ook mijn dorp het slachtoffer ;) geworden van deze fietspaden kots. Wat te doen? Verwijderen en de editor inlichten? Is dit nieuwe policy? Kom ik zo af en toe ook wel tegen. Grootste probleem lijkt het gebruik van Potlatch te zijn (zonder hier nu de gebruiker dan wel Potlatch direct de schuld van te geven ;-), het kost enige oefening om wegen op de juiste manier met elkaar te verbinden. Ik zou de gebruiker benaderen en hem de hint geven dat JOSM (of misschien merkaartor, weet niet of die hetzelfde probleem heeft) misschien beter werkt. -- Freek ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietspaden kots
Maarten Deen wrote: Stefan de Konink wrote: Matthijs Benschop wrote: Het valt mij vaak op dat mensen ten onrechte een fietspad naast een weg tekenen, terwijl die weg al de tag cycleway=track etc hebben. Het lijkt me wenselijk dat een cycle way die naast een weg loopt niet in de zelfde weg is opgenomen. Analoog aan als een weg uit twee banen met een midden berm bestaat je hem als twee 'one ways' tekent. Bedoel je dat je die dan apart moet taggen? Helemaal :) Dat zou betekenen dat je naast zo'n beetje elke provinciale weg een fietspad moet gaan tekenen. Daar teken ;) ik toch niet voor. Exact :) Alleen fietspaden die op de weg zelf aangegeven zijn met markering mag je als 1 weg tekenen ;) M.i. is een fietspad dat langs een weg loopt onderdeel van de weg, behalve als het een duidelijk andere loop heeft. Dat is niet de gangbare gedachte. Immers als je over een weg naast de hoofdweg fietst heb je echt een compleet andere GPS trace. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietspaden kots
On Friday 26 December 2008 17:19:56 Freek wrote: Kom ik zo af en toe ook wel tegen. Grootste probleem lijkt het gebruik van Potlatch te zijn (zonder hier nu de gebruiker dan wel Potlatch direct de schuld van te geven ;-), het kost enige oefening om wegen op de juiste manier met elkaar te verbinden. Een andere oorzaak van losse fietspaden is ook nog steeds de AND import. Alle wegen van voor de import zijn toen verwijderd, maar de fietspaden niet. Die zitten dus niet vast aan de geïmporteerde wegen. Het Jaagpad in de bocht van de Oude Rijn in de tweede link hierboven is daar een goed voorbeeld van. -- m.v.g., Cartinus ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietspaden kots
Cartinus wrote: On Friday 26 December 2008 17:19:56 Freek wrote: Kom ik zo af en toe ook wel tegen. Grootste probleem lijkt het gebruik van Potlatch te zijn (zonder hier nu de gebruiker dan wel Potlatch direct de schuld van te geven ;-), het kost enige oefening om wegen op de juiste manier met elkaar te verbinden. Een andere oorzaak van losse fietspaden is ook nog steeds de AND import. Alle wegen van voor de import zijn toen verwijderd, maar de fietspaden niet. Die zitten dus niet vast aan de geïmporteerde wegen. Het Jaagpad in de bocht van de Oude Rijn in de tweede link hierboven is daar een goed voorbeeld van. We zouden natuurlijk wel even een lijstje met losse wegen kunnen maken :) Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietspaden kots
Op Fri, 26 Dec 2008 17:04:35 +0100, schreef Stefan de Konink: Matthijs Benschop wrote: Het valt mij vaak op dat mensen ten onrechte een fietspad naast een weg tekenen, terwijl die weg al de tag cycleway=track etc hebben. Het lijkt me wenselijk dat een cycle way die naast een weg loopt niet in de zelfde weg is opgenomen. Analoog aan als een weg uit twee banen met een midden berm bestaat je hem als twee 'one ways' tekent. Maar feitelijk is het (in veel gevallen) wel dezelfde weg. Ik heb geleerd dat een weg loopt van berm tot berm. Eventuele bermen om verschillende rijbanen te scheiden dus niet meegerekent. Zowiezo een middenberm de aanleiding te laten zijn voor 2x oneway lijkt mij erg overdreven. Zie dit voorbeeld: http://www.openstreetmap.org/?lat=52.082466lon=4.900045zoom=18layers=B000FTF Ook qua naamgeving zal het fietspad hetzelfde zijn als de weg waar hij naast ligt. Als ik werkelijk elk fietspad naast een weg ga tekenen dan wordt osm de lelijkste kaart die er is... En de voorbeelden heb ik al gegeven. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietspaden kots
Matthijs Benschop schreef: Als ik werkelijk elk fietspad naast een weg ga tekenen dan wordt osm de lelijkste kaart die er is... En de voorbeelden heb ik al gegeven. OSM is al de lelijkste kaart die ik ooit gezien heb... althans, de ruwe versie in JOSM. Daarom zijn er renderers, die voor een duidelijke en mooie kaart moeten zorgen. En die renderers zouden hetzelfde moeten laten zien voor een losliggende highway=cycleway en een cycleway=track op een bestaande rijweg, aangezien beide manieren van tagging hetzelfde betekenen. Persoonlijk vind ik losliggende cycleways duidelijker. Ze zijn sowieso flexibeler omdat je per richting verschillende tags kan gebruiken. Het enige is dat ze lastiger aan te maken zijn; als je dat stoort, dan kan je altijd cycleway-track gebruiken. No problem. Eugene ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietspaden kots
Matthijs Benschop wrote: Op Fri, 26 Dec 2008 17:04:35 +0100, schreef Stefan de Konink: Matthijs Benschop wrote: Het valt mij vaak op dat mensen ten onrechte een fietspad naast een weg tekenen, terwijl die weg al de tag cycleway=track etc hebben. Het lijkt me wenselijk dat een cycle way die naast een weg loopt niet in de zelfde weg is opgenomen. Analoog aan als een weg uit twee banen met een midden berm bestaat je hem als twee 'one ways' tekent. Maar feitelijk is het (in veel gevallen) wel dezelfde weg. Ik heb geleerd dat een weg loopt van berm tot berm. Eventuele bermen om verschillende rijbanen te scheiden dus niet meegerekent. Binnen osm heeft iedere door berm gescheiden weghelft een eigen lijntje. [Geen discussie; anarchistische afspraak] Zowiezo een middenberm de aanleiding te laten zijn voor 2x oneway lijkt mij erg overdreven. Zie dit voorbeeld: Niet overdreven, routeren is een van de redenen. Als ik werkelijk elk fietspad naast een weg ga tekenen dan wordt osm de lelijkste kaart die er is... En de voorbeelden heb ik al gegeven. Lelijkheid heeft niets met OSM te maken maar met de renderer van de kaart. Als de renderer denkt dat het samenvoegen van wegen een mooier plaatje oplevert, moet mapnik etc. dat doen. Ik ben het met je eens dat momenteel over de logica daarvoor niet goed wordt gebruikt. En Merkaartor volgens mij de enige tool is die daadwerkelijk relaties kent tussen onafhankelijke wegen. Zelf zou ik best nog verder gaan, zoals ook op de RWS kaarten gebeurd, de oppervlakten van de wegen weergeven op de kaart. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-de] Benutzung von is_in
Stefan Hirschmann wrote: André Reichelt wrote: Miriam Tolke schrieb: Um das Ganze mit is_in in den Griff zu bekommen kommt es dann zu sowas: is_in:Roth,Mittelfranken,Bayern,Bundesrepublik Deutschland,Europe Soweit ich informiert bin, ist dieses Tagging-Schema veraltet. Heute löst man etwas eigentlich mit Relations. Es gibt zwar auch eine Relation dafür. Aber: is_in=Europe als Relation? Spätestens da merkt man, dass Relationen nicht unbedingt etwas sind, was skalieren. Im Gegenteil sind sie nahezu optimal, wenn man nur die Ebene darüber referenziert. Es ist dann die entsprechende Frage der Software-Unterstützung, entsprechende Mehrfachvererbungen oder Hierarchien aufzulösen. Beispielsweise kann man sich damit alles bis zur Ortsteilebene innerhalb eines Landkreises auswählen, ohne die Kreisgrenzen zu kennen. opengeodb nutzt part of, Teil von, is in oder wie auch immer man das nennen mag. Die Relation kann dann entsprechend in beide Richtungen aufgelöst werden. Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Hallo! Dimitri Junker schrieb: Ob ein Radweg ein Track auf dem Bürgersteig oder eine lane auf der Straße ist, ist für unsichere, ältere Radfahrer sehr entscheidend. Diese Unterscheidungsmöglichkeit gibt es derzeit aber nur bei der 1-Weg Methode, nämlich cycleway=lane oder track. Zeichnet man den Fahrradweg einzeln ist er highway=cycleway, da gibt es (noch) keine Unterscheidung. Ich kenne hierfür, dass zu highway=cycleway ZUSÄTZLICH cycleway= lane/track hinzugesetzt wird. -- Mit freundlichen Gruessen Wolfgang Wienke ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Benutzung von is_in
g.d wrote: (Wir haben hier eine Liste der offiziellen Verwaltungseinheiten, aufgestellt vom hiesigen statistischen Amt, der INSEE. Diese Liste hört aber auf der Rathausebene auf, Ortsteile, Weiler usw sind da nicht aufgelistet, und die parallelen strukturellen Verwaltungen sind nicht berücksichtigt, sodass in dieser Liste dreimal die Hälfte der Informationen fehlt...). Hallo Gerhard, wo ist hier und welche Liste meinst du? Hier in F ist jedoch eine derartige Hierarchie-Struktur nicht direkt anwendbar : Es gibt hier Stadtviertel, Stadtteile, Weiler, Wahlbezirke, Gemeinden, Gemeindezusammenschlüsse (mit einem gemeinsamen Rathaus), Kantone (die auch Wahlbezirke sind), Kantone in F? Frankfurt? Frankreich? Dein hier ist etwas unscharf. Verwaltungsgruppierungen (die uns von oben aufgedrängt worden sind), freiwillige Gemeinde-Gemeinschaften (wo jedes Dorf seine eigene Verwaltungshoheit beibehält, jedoch gemeinsame Aufgaben wie Müll, Schulen, Sportinstallationen, Ortskernentwicklung, Bauraumplanung, GIS usw der gemeinschaftlichen Verwaltung überträgt), In Deutschland hört das von oben auf Gemeinde-Ebene auf: Deutschland - Bundesländer - evtl. Regierungsbezirke - nicht amtlich: Regionen - Kreise (Landkreise, kreisfreie Städte) - Gemeinden Einige dieser Gemeinden schliessen sich auf freiwilliger Basis zu Verwaltungsgemeinschaften, -einheiten oder Ämtern zusammen. Entwicklungsverträge zwischen Gemeinden (Contrat de Pays), wo sich Gemeinden zu einem gemeinsamen Ziel zusammentun, wenn die Verwaltungseinheiten nicht den topografischen oder ökonomischen Gegebeheiten entsprechen : Zu Beispiel das Pays de Trocnçais, ein Vertrag, der um den Wald von Tronçais enstanden ist, und über vier Départements und drei Régions reicht. Und auch Interessens-Zusammenschlüsse für Skigebiete und Strandbäder, die mehrere Départements Plus die üblichen Départements und Régions (und natürlich auch irgendwelche touristische Strassen wie die Route Jacques Cœuer, die Route des Vins, usw). Solche Gemeinschaften sind aber Zweckgemeinschaften - sprich bei mehreren Zwecken in einer Gemeinde können sich mehrere Zusammenmschlüsse bilden, die völlig unterschiedlich organisiert sind. Beispielsweise haben die Grenzen von Postleitzahlen, Telefon-Vorwahlen, Winzergenossenschaften, Bio-Einkaufsgenossenschaften usw. nur im Ausnahmefall identische Grenzen. Ich sehe auf der Deutschlandkarte, dass Stadtteile nicht im Namen ausgewiesen sind, nicht Stuttgart Bad Cannstatt sondern Bad Canstatt, nicht Göppingen Hohenstaufen sondern Hohenstaufen, nicht Karlsruhe Rüppurr sondern Rüppurr usw. Ist das gewollt ? Defintiv ja - wobei es Ausnahmen gibt bzw. wo örtliche Gepflogenheiten eine höhere Ebene mitziehen. Personenbahnhof Bad Cannstatt zieht den Ortsnamen mit, obwohl Personenbahnhof reichen würde. Erfurt-Mitte scheint etwas anderes zu sein als Erfurt-Altstadt. Dann muss man die Zugehörigkeiten mit is_in ausdrücken (?). Das schein in D nicht immer konsequent der Fall zu sein, dehalb mein Frage. is_in und Relationen haben untergeordnete Priorität. Vieles davon kann und sollte automatisch hinzugefügt werden. Das sind in keinsterweise irgendwelche Kritiken ! Ich versuch' nur, herauszufinden, was die gemeinsamen Prinzipien sind, oder der kleinste gemeinsame Nenner ist, damit wir von Euch abschreiben können... ;-) Wie haltet Ihr das, im Allgemeinen ? Ich selbst favorisiere die Nutzung eines Amtlichen Gemeindeschlüssels. Beispielsweise hat Karlsruhe den AGS 08212 (08: Baden-Württemberg, 082: Regierungsbezirk Karlsruhe, 08212: Stadt Karlsruhe, 08212000 Karlsruhe auf Gemeinde-Ebene. Bis auf Gemeinde-Ebene ist das amtlich und bundeseinheitlich vorgegeben. Darunter erfinde ich mehr oder weniger zufällig Erweiterungen des AGS. So hat der Stadtteil Beiertheim-Bulach die 0821200013 und das Stadtviertel Bulach den AGS 08212000132 Schon allein aus den Stellen des AGS ergibt sich eine Hierarchisierung, was worin liegt - acht Stellen AGS + fünf Stellen Strassennummer geht herab bis auf die Strassenebene, erweitert um drei Stellen auch bis auf Hausnummern-Ebene. Ist es notwendig, in jedem Weiler die ganze Hierarchie bis 'rauf nach Europe zu wiederholen, Bei is_in ja. oder genügt es, die jeweils höhere Hierarchiestufe einzugeben, Bei Relationen IMHO ja aber nicht, wenn es sich um geografisch distante und getrennt gewachsene Ortschaften handelt, wie Berhausen (Pfinztal, Karlsruhe), oder Suburb scheint mir als Vorstadt (de) oder banlieue (fr) übersetzbar zu sein, aber nicht als Teilort (?). Es gibt keine klare Definition, was Teil wovon ist. Beispielsweise wird mancherorts ein Stadtteil dem Stadtviertel untergeordnet, anderswo ist es genau umgekehrt. Manche haben Stadtbezirke, Statistische Bezirke, Stadtquartiere usw. In der opengeodb wird daher nur die Teil-von-Beziehung gepflegt und je nach Kenntnis um den Typ ergänzt, wo man Stadtteil
Re: [Talk-de] Kreuzung Radwege
1) Soll cycleway=track wenn immer sinnvoll benutzt werden, also immer außer wenn die Situation von der Norm abweicht, der Fahrradweg also nicht unmittelbar neben der Straße verläuft. Falls Ja: Die Probleme lösen, also Fahrradweg nur auf einer Seite, oder auf einer Seite als cycleway=track und auf der anderen als cycleway=lane Falls Nein: Die Probleme lösen, also die verschiedenen Wege zu einer Einheit per Relation kombinieren, u.a. damit aus einer Kreuzung nicht 3 werden, damit Adressen sowohl per Auto als auch per Fahrrad erreichbar sind,... . Wozu gehört der Bürgersteig? Zur Straße oder zum Fahrradweg, oder muß der auch einzeln gemappt werden. Meist ist ja der Fahrradweg zwischen Straße und Bürgersteig - es kann also nicht sein, daß man innen die Straße mit Bürgersteig mappt und außen den Fahrradweg, vor allem wenn man die Wirklichkeit möglichst genau mappen will. Meiner Erfahrung nach verläuft ein Radweg, wenn er baulich getrennt ist, meistens entweder nicht immer parallel zur Straße (macht Schlenker etc.), oder es gibt an verschiedenen Stellen Querverbindungen zur Straße (Hofeinfahrten, Verbindungen nur zwischen Radweg und Straße). Da ich besonders die Verbindungswege für wichtig halte (damit man z.B. weiß, wo man wieder auf die Straße kommt oder sie überqueren kann), würde ich für die Antwort nein plädieren. Bei cycleway=track gehen diese Informationen sonst leider verloren. Wenn der Radweg auf dem Bürgersteig ist, sehe ich das noch nicht als bauliche Trennung an; man kann ja an jeder Stelle wieder auf die Straße wechseln. Wo eine bauliche Trennung vorliegt, ist doch normalerweise gar kein extra Bürgersteig vorhanden (= gemeinsamer Fuß- und Radweg), oder der Bürgersteig ist tatsächlich direkt an der Straße, noch vor dem Radweg. Grüße, Marc -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC
Michael Bemmerl schrieb: Halb-OT: Event Codes gibt's... $Event[1516] = bomb alert; Naja, das ist in D, mit den ganzen Souveniers aus 39-45, nicht ganz abwegig. Man denke an den armen Menschen, der vor ein paar Jahren mit seiner Asphaltfraese beim Ausbau der A3 so ein Ding getroffen hat. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Hallo, Ich kenne hierfür, dass zu highway=cycleway ZUSÄTZLICH cycleway= lane/track hinzugesetzt wird. Ist das irgendwo so dokumentiert? Wenn nicht wäre das ja ein doppelter Fahrradweg Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Hallo, http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Workshops/Linienb%C 3%BCndel ich gehe mal einige Punkte durch: 1. Die Wege einfach (auf bisherige Art) separat erfassen: * Vorteile komplexere geometrische Zusammenhänge einfacher erfassbar Aber nur wenn man beliebig weit reinzoomen kann. Druckt man eine Karte aus oder speichert eine Pixelkarte auf dem GPS-Gerät kann es sehr unübersichtlicher werden. 2. Die Wege auf einfache (bisherige) Art als Attribut an die Straße hängen. * Vorteile: allerdings größere Abweichung des gerenderten Bilds von der realen Situation) Wir sind aber alle mit Karten groß geworden die eine Straße nur als eine Linie zeichnen. Wenn ich ein genaues Abbild will nehme ich ein Sat-Foto. Nachteile: * Freiheit wird eingeschränkt. Naja, wer braucht OSM um sich als freier Mensch zu fühlen? Richtungsabhängiges Taggen schwierig. Umdrehen des ways gefährlich. Weder left/right noch die Angabe als Himmelsrichtung konnten bisher einen Großteil der Teilnehmer der ML überzeugen. Ich sehe das Problem immer noch nicht. Es gibt nur eine überschaubare Anzahl Editoren, denen könnte man das beibringen. # Es könnte zu einer starken Zersplitterung der Wege in kleine Abschnitte kommen. Es sei denn man vergibt Atribute mit from to und via, also 2 Nodes und dem Weg. Damit wäre ein zersplittern unnötig, und die Richtungsabhängigkeit wäre auch drin. evtl. unübersichtlich beim graphischen Editieren, weil den Tags keine grafische Entsprechung zur Seite steht Ich behaupte mal, daß es in 99% der Fälle übersichtlicher ist wenn nur ein Weg da ist, nämlich immer wenn man andere Wege bearbeitet. Für den Fall, daß man die Atribute eines Weges anschaulich überprüfen möchte könnte man JOSM eine Art Zoom-Fenster verpassen, da würde dann die selektierte Straße detailiert gezeichnet. In einer ersten Version nur zur Veranschaulichung, erkennt man a Fehler muß man per Hand Tags ändern. In einer 2. Version könnte man dort editieren, und JOSM würde das in Tags umrechnen. 3. Die Wege auf komplexere Art als Attribut an die Straße hängen. Wahrscheinlich die einzig sinnvolle Methode, sollte dann aber mit dem gerade beschriebenen Zoom-Fenster kombiniert werden, sonst zu kompliziert. Die Spuren in diesem Versuch eines Datenmodells gehen von links nach rechts in Richtung des Wegs. Wenn man die Richtung eines Wegs umdreht, sollte ein Editor nachfragen, ob er die Reihenfolgen und Richtungen der lanes mitdrehen soll oder nicht. Kann mir jemand eine Situation nennen wo nicht gedreht werden muß? http://tobias-knerr.de/josm/lanetool/ Irgendwie stimmt da was nicht, wenn ich versuche lanetools.jar zu laden erhalte ich lanetools.zip ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Hallo, Meiner Erfahrung nach verläuft ein Radweg, wenn er baulich getrennt ist, meistens entweder nicht immer parallel zur Straße (macht Schlenker etc.), oder es gibt an verschiedenen Stellen Querverbindungen zur Straße Als baulich getrennt (also cycleway=track) gilt schon ein Bordstein, und da ist der Fahrradweg meist parallel zur Straße und weniger als 1m von dieser entfernt. Und Querverbindungen taggen macht nur sinn wenn sie selten sind. Wenn man bei jeder Einfahrt, also etwa alle 20m wechseln kann schaut keiner auf die Karte oder sein Navi um zu sehen wann die nächste Einfahrt kommt. Wenn der Radweg auf dem Bürgersteig ist, sehe ich das noch nicht als bauliche Trennung an; So steht es aber im Wiki - wir sind uns also da einig. Ein Beispiel für einen meiner Meinung nach unnötigen abgesetzten Radweg ist hier in Aachen die Triererstr. S.: http://www.informationfreeway.org/?lat=50.769lon=6.120zoom=17 und http://maps.google.de/maps?oe=UTF- 8hl=deq=ie=UTF8om=1ll=50.769108,6.120047spn=0.001218,0.002355t=hz=19 vor allem da die Querverbindungen nicht eingetragen sind. Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GDV Datenteinste
Hallo Sven, Sven Anders schrieb: http://www.gdv.com/down/gdv_datendienste.php *hüstel* = Kartografisch hochwertiger Stadtplan-Kartendienst Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßen in in Baugebiet mit Vorerschlie ßung
Johann H. Addicks schrieb: Martin Koppenhoefer schrieb: verabschiedet, das ist vor den Bauarbeiten, die Auslegung war *19.06.2007 bis 19.07.2007. Findest Du was aktuelleres (ohne dafür auf ein Amt zu gehen)? Das nicht, aber das hier ist cool: http://www.competitionline.de/4008376/alias/beitraege ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Papierkarte (DIN A0 oder ähnliche Größe) drucken
Wolfgang W. Wasserburger schrieb: ;-) hpgl2dxf haben wir früher mal verwendet -googlen reicht vielleicht Das war noch zu Stiftzeiten, oder? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Dimitri Junker schrieb: Hallo, Meiner Erfahrung nach verläuft ein Radweg, wenn er baulich getrennt ist, meistens entweder nicht immer parallel zur Straße (macht Schlenker etc.), oder es gibt an verschiedenen Stellen Querverbindungen zur Straße Als baulich getrennt (also cycleway=track) gilt schon ein Bordstein, und da ist der Fahrradweg meist parallel zur Straße und weniger als 1m von dieser entfernt. Und Querverbindungen taggen macht nur sinn wenn sie selten sind. Wenn man bei jeder Einfahrt, also etwa alle 20m wechseln kann schaut keiner auf die Karte oder sein Navi um zu sehen wann die nächste Einfahrt kommt. Wenn der Radweg auf dem Bürgersteig ist, sehe ich das noch nicht als bauliche Trennung an; So steht es aber im Wiki - wir sind uns also da einig. Nicht über alles das im Wiki steht herrscht auch tatsächlich Konsens. Das muss nichtmal aufgrund von eigenmächtigen Änderungen oder falschen Angaben so sein, sondern kann schon eine missverständliche Übersetzung oder eine etwas andere Formulierung sein. Zudem steht in den Map Features sowieso baulich abgesetzt und nicht baulich getrennt. Diese Unterscheidung finde ich wichtig. Im einen Fall ist der Weg lediglich baulich von der Straße abgesetzt um sie leichter unterscheiden zu können (track), während im anderen Fall der Weg tatsächlich von der Straße getrennt ist und man nicht mehr einfach darauf wechseln kann (eigener Weg). Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC
Ich werde mich an die BAST wenden, da ich dieses Thema gerade im Rahmen eines studentischen Projektes bearbeiten / untersuchen lassen möchte. Eine andere Gruppe wird den GeoRSS-Feed von Antenne Bayern verwenden. Mit freundlichen Grüßen / Regards / Cordialement Dr. Franz-Josef Behr Participate in http://www.opengeocoding.org! Ulf Lamping schrieb: John07 schrieb: Sofern ich das richtig verstanden habe, braucht man Tabellen, um die TMC-Daten den OSM/Navigations-Daten zuzuordnen. Bei Openrouteservice ist das ja möglich, warum sollte es also nicht auch für jede andere OSM-Anwendung möglich sein bzw. wenn ORS die Daten nutzen kann/darf, warum dann nicht auch andere OSM-Anwendungen? Außerdem haben die von ORS wohl Erfahrung mit TMC in Verbindung mit OSM, daher finde ich meinen Hinweis durchaus nützlich. Dann google doch mal ein wenig bevor du fragst (hab ich auch gemacht) ;-) Die Liste kannst du kostenlos unter: http://www.bast.de/nn_42544/DE/Aufgaben/abteilung-v/referat-v2/Location-Code-List/location-code-list-start.html zugeschickt bekommen, wenn du einer Reihe von Bedingungen zustimmst und genau beschreibst wofür du das ganze haben willst. Problematisch dabei: 3. Der Nutzer erhält eine kostenfreie Lizenz zur Nutzung der LCL 7.01 für den angegebenen Verwendungszweck. Für fortgeschriebene Versionen der Location Code List gilt dieses Nutzungsrecht nicht. Die Weitergabe der Location Code List durch den Nutzer an Dritte ist nicht zulässig. Somit kommst du an diese List wohl ran, aber einfach so in OSM einpflegen ist wegen dieser Lizenz einfach nicht drin. Nett fragen kann ja mal *einer* (der vielleicht mit sowas schon etwas Erfahrung hat) beim Bast, die Behörden scheinen in letzter Zeit ja allgemein kooperativer als noch vor nem halben Jahr zu sein :-) Gruß, ULFL P.S: Die andere Info die man braucht sind die Event Codes (sowas wie ID 17=Stau), die konnte ich aber nicht so ohne weiteres finden (gibt's irgendwo in einer IEEE/ISO Norm für so 230Dollar) ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de begin:vcard fn:Dr. Franz-Josef^Behr n:Behr;Franz-Josef org:Stuttgart University of Applied Sciences (SUAS);Faculty of Geomatics, Computer Science and Mathematics adr;quoted-printable:;;Schellingstra=C3=9Fe 24, ;Stuttgart;;D-70174;Germany title:Prof. tel;work:+49) 711/8926-2606 tel;home:+49 (0)721 / 453980-1 url:http://www.hft-stuttgart.de/ version:2.1 end:vcard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Dimitri Junker schrieb: Die Spuren in diesem Versuch eines Datenmodells gehen von links nach rechts in Richtung des Wegs. Wenn man die Richtung eines Wegs umdreht, sollte ein Editor nachfragen, ob er die Reihenfolgen und Richtungen der lanes mitdrehen soll oder nicht. Kann mir jemand eine Situation nennen wo nicht gedreht werden muß? Zum Beispiel wenn man den Weg dafür dreht um die falschrum getaggten richtungsabhängigen Tags zu korrigieren. Aber das dürfte vermutlich selten vorkommen, da hast du recht. Andererseits kommt Weg drehen sowieso selten vor, insofern ist es vermutlich auch nicht sonderlich schlimm wenn man da gefragt wird. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC
Interessant: Der 1. Google-Eintrag ist mit dem Download-Link der Liste verlinkt, ohne dass man irgendwas bestellen oder angeben muss. Durch die richtigen Stichwörter findet man die Liste auch über die offizielle Suchfuntkion von BASt.de :-) Die Tags der Liste sind ziemlich ähnlich zu unseren :- Dr. Franz-Josef Behr schrieb: Ich werde mich an die BAST wenden, da ich dieses Thema gerade im Rahmen eines studentischen Projektes bearbeiten / untersuchen lassen möchte. Eine andere Gruppe wird den GeoRSS-Feed von Antenne Bayern verwenden. Mit freundlichen Grüßen / Regards / Cordialement Dr. Franz-Josef Behr Participate in http://www.opengeocoding.org! Ulf Lamping schrieb: John07 schrieb: Sofern ich das richtig verstanden habe, braucht man Tabellen, um die TMC-Daten den OSM/Navigations-Daten zuzuordnen. Bei Openrouteservice ist das ja möglich, warum sollte es also nicht auch für jede andere OSM-Anwendung möglich sein bzw. wenn ORS die Daten nutzen kann/darf, warum dann nicht auch andere OSM-Anwendungen? Außerdem haben die von ORS wohl Erfahrung mit TMC in Verbindung mit OSM, daher finde ich meinen Hinweis durchaus nützlich. Dann google doch mal ein wenig bevor du fragst (hab ich auch gemacht) ;-) Die Liste kannst du kostenlos unter: http://www.bast.de/nn_42544/DE/Aufgaben/abteilung-v/referat-v2/Location-Code-List/location-code-list-start.html zugeschickt bekommen, wenn du einer Reihe von Bedingungen zustimmst und genau beschreibst wofür du das ganze haben willst. Problematisch dabei: 3. Der Nutzer erhält eine kostenfreie Lizenz zur Nutzung der LCL 7.01 für den angegebenen Verwendungszweck. Für fortgeschriebene Versionen der Location Code List gilt dieses Nutzungsrecht nicht. Die Weitergabe der Location Code List durch den Nutzer an Dritte ist nicht zulässig. Somit kommst du an diese List wohl ran, aber einfach so in OSM einpflegen ist wegen dieser Lizenz einfach nicht drin. Nett fragen kann ja mal *einer* (der vielleicht mit sowas schon etwas Erfahrung hat) beim Bast, die Behörden scheinen in letzter Zeit ja allgemein kooperativer als noch vor nem halben Jahr zu sein :-) Gruß, ULFL P.S: Die andere Info die man braucht sind die Event Codes (sowas wie ID 17=Stau), die konnte ich aber nicht so ohne weiteres finden (gibt's irgendwo in einer IEEE/ISO Norm für so 230Dollar) ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC
Am 26.12.08 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Interessant: Der 1. Google-Eintrag ist mit dem Download-Link der Liste verlinkt, ohne dass man irgendwas bestellen oder angeben muss. Durch die richtigen Stichwörter findet man die Liste auch über die offizielle Suchfuntkion von BASt.de :-) Die Tags der Liste sind ziemlich ähnlich zu unseren :- Cool. Hat noch wer eine Beschreibung des eigentlichen Protokolls und wie das bei geeigneten GPS-Empfängern im NMEA-Datenstrom eingebettet ist? Wäre toll das implementieren zu können. Zu Java und TMC finde ich nur ein leeres Projekt ohne jeden Code. Kennt jemand verständlich dokumentierte Implementierunen des Protokolls? Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC // Konkurrenz
Marcus Wolschon schrieb: Wäre toll das implementieren zu können. Das stimmt in der Tat. Achja, falls es noch nicht nicht durchgesickert ist: Navteq hat im November T-Systems Traffic (also TMCpro) aufgekauft. HD-Traffic = TomTom (TeleAtlas) in Zusammenarbeit mit Vodafone TMCpro = Navteq (Nokia) in Zusammenarbeit mit Projekt Mobile Millennium ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC // Konkurrenz
Am 26.12.08 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Marcus Wolschon schrieb: Wäre toll das implementieren zu können. Das stimmt in der Tat. Achja, falls es noch nicht nicht durchgesickert ist: Navteq hat im November T-Systems Traffic (also TMCpro) aufgekauft. HD-Traffic = TomTom (TeleAtlas) in Zusammenarbeit mit Vodafone TMCpro = Navteq (Nokia) in Zusammenarbeit mit Projekt Mobile Millennium Beide kostenpflichtig und brauchen eine Mobilfunk-Verbindung. Zur Einbindung von TMC in NMEA 2.0 habe ich was gefunden. http://www.capuzza.com/detail.php?ID=123764 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC // Konkurrenz
Marcus Wolschon schrieb: Beide kostenpflichtig und brauchen eine Mobilfunk-Verbindung. Ich weiß, wollte nur eine kurze Übersicht einbringen. Ich schätze aber, dass man die Daten jetzt eh nicht mehr für dritte Zwecke verwenden kann. Zur Einbindung von TMC in NMEA 2.0 habe ich was gefunden. http://www.capuzza.com/detail.php?ID=123764 Andersrum kann ich dir übrigens helfen: Für RDS in FM gibt es mittlerweile sehr gute Software :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Wenn der Radweg auf dem Bürgersteig ist, sehe ich das noch nicht als bauliche Trennung an; So steht es aber im Wiki - wir sind uns also da einig. Nicht über alles das im Wiki steht herrscht auch tatsächlich Konsens. Das muss nichtmal aufgrund von eigenmächtigen Änderungen oder falschen Angaben so sein, sondern kann schon eine missverständliche Übersetzung oder eine etwas andere Formulierung sein. Zudem steht in den Map Features sowieso baulich abgesetzt und nicht baulich getrennt. Diese Unterscheidung finde ich wichtig. Im einen Fall ist der Weg lediglich baulich von der Straße abgesetzt um sie leichter unterscheiden zu können (track), während im anderen Fall der Weg tatsächlich von der Straße getrennt ist und man nicht mehr einfach darauf wechseln kann (eigener Weg). Ah! Das ist dann also der Unterschied zwischen cycleway=track und eigenem Radweg. Allerdings ist auf dem Foto rechts daneben etwas mehr als ein Bordstein dazwischen, wenn auch immer noch direkt an die Straße angrenzend... Grüße, Marc -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC
Dr. Franz-Josef Behr schrieb: Ich werde mich an die BAST wenden, da ich dieses Thema gerade im Rahmen eines studentischen Projektes bearbeiten / untersuchen lassen möchte. Ist bereits erfolgt. Bleibt nur noch die Arbeit zu erledigen... Eine andere Gruppe wird den GeoRSS-Feed von Antenne Bayern verwenden. begin:vcard fn:Dr. Franz-Josef^Behr n:Behr;Franz-Josef org:Stuttgart University of Applied Sciences (SUAS);Faculty of Geomatics, Computer Science and Mathematics adr;quoted-printable:;;Schellingstra=C3=9Fe 24, ;Stuttgart;;D-70174;Germany title:Prof. tel;work:+49) 711/8926-2606 tel;home:+49 (0)721 / 453980-1 url:http://www.hft-stuttgart.de/ version:2.1 end:vcard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Gewässern
Hi! Andreas Labres schrieb: Sven Geggus wrote: Diese Objekte sind ja vieles, aber ganz bestimmt nicht natural. Die Diskussion hamma doch ständig und irgendwie isses müßig... Wasser is Wasser und immer natural. Wie die Ansammlung von Wasser zustandekommt, ist doch in erster Linie irrelevant. Relevant ist für den Renderer, daß er da Blau hinpappt, und für den Router (zumindest für die Straßen/Wege-gebundenen), daß es ein Hindernis ist. Irgendwie scheint mir das aber reichlich inkonsequent. Bei Wäldern wird großer Wert darauf gelegt, daß die Bäume nicht natural=wood sondern landuse=forest sind. Bei Wasser sollen Fischteiche und Stauseen als water=natural gelten? bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC // Konkurrenz
TMCpro = Navteq (Nokia) in Zusammenarbeit mit Projekt Mobile Millennium Beide kostenpflichtig und brauchen eine Mobilfunk-Verbindung. TMCpro ist kostenpflichtig, ja. Allerdings einmalig pro ausgeliefertem Gerät bzw. Software vom Navihersteller, eine Mobilfunkverbindung wird nicht benötigt, da es genau wie TMC über Radiosender übertragen wird. CU Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC // Konkurrenz
Am 26.12.08 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Andersrum kann ich dir übrigens helfen: Für RDS in FM gibt es mittlerweile sehr gute Software :-) Sotware? Gibts da ein einheitliches Protokoll, wie ein Consumer-Empfänger das in einen Computer übergibt? Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] namesearch
Ich bin zwar froh, dass der Namesearch auf der openstreetmap.org nicht mehr in minuntenlange Timeouts rennt wie in den letzten Tagen. Aber die mehr als Bildschirmlangen Fehlermeldungen finde ich auch nicht erquicklich. Weiss jemand, was derzeit dort das Problem ist? -jha- p.s.: Error contacting gazetteer.openstreetmap.org: # /usr/lib/ruby/1.8/rexml/document.rb:91:in `' /usr/lib/ruby/1.8/rexml/element.rb:868:in `add' /usr/lib/ruby/1.8/rexml/child.rb:21:in `initialize' /usr/lib/ruby/1.8/rexml/parent.rb:13:in `initialize' /usr/lib/ruby/1.8/rexml/element.rb:59:in `initialize' /usr/lib/ruby/1.8/rexml/element.rb:866:in `new' /usr/lib/ruby/1.8/rexml/element.rb:866:in `add' /usr/lib/ruby/1.8/rexml/element.rb:297:in `add_element' /usr/lib/ruby/1.8/rexml/document.rb:98:in `add_element' /usr/lib/ruby/1.8/rexml/parsers/treeparser.rb:33:in `parse' /usr/lib/ruby/1.8/rexml/document.rb:227:in `build' /usr/lib/ruby/1.8/rexml/document.rb:43:in `initialize' /home/rails/app/controllers/geocoder_controller.rb:263:in `new' /home/rails/app/controllers/geocoder_controller.rb:263:in `fetch_xml' /home/rails/app/controllers/geocoder_controller.rb:121:in `search_osm_namefinder' /home/rails/app/controllers/geocoder_controller.rb:21:in `search' /var/lib/gems/1.8/gems/actionpack-2.0.2/lib/action_controller/base.rb:1158:in `send' /var/lib/gems/1.8/gems/actionpack-2.0.2/lib/action_controller/base.rb:1158:in `perform_action_without_filters' /var/lib/gems/1.8/gems/actionpack-2.0.2/lib/action_controller/filters.rb:697:in `call_filters' /var/lib/gems/1.8/gems/actionpack-2.0.2/lib/action_controller/filters.rb:689:in `perform_action_without_benchmark' /var/lib/gems/1.8/gems/actionpack-2.0.2/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue' /usr/lib/ruby/1.8/benchmark.rb:293:in `measure' /var/lib/gems/1.8/gems/actionpack-2.0.2/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue' /var/lib/gems/1.8/gems/actionpack-2.0.2/lib/action_controller/rescue.rb:199:in `perform_action_without_caching' /var/lib/gems/1.8/gems/actionpack-2.0.2/lib/action_controller/caching.rb:678:in `perform_action' /var/lib/gems/1.8/gems/activerecord-2.0.2/lib/active_record/connection_adapters/abstract/query_cache.rb:33:in `cache' /var/lib/gems/1.8/gems/activerecord-2.0.2/lib/active_record/query_cache.rb:8:in `cache' /var/lib/gems/1.8/gems/actionpack-2.0.2/lib/action_controller/caching.rb:677:in `perform_action' /var/lib/gems/1.8/gems/actionpack-2.0.2/lib/action_controller/base.rb:524:in `send' /var/lib/gems/1.8/gems/actionpack-2.0.2/lib/action_controller/base.rb:524:in `process_without_filters' /var/lib/gems/1.8/gems/actionpack-2.0.2/lib/action_controller/filters.rb:685:in `process_without_session_management_support' /var/lib/gems/1.8/gems/actionpack-2.0.2/lib/action_controller/session_management.rb:123:in `process' /var/lib/gems/1.8/gems/actionpack-2.0.2/lib/action_controller/base.rb:388:in `process' /var/lib/gems/1.8/gems/actionpack-2.0.2/lib/action_controller/dispatcher.rb:171:in `handle_request' /var/lib/gems/1.8/gems/actionpack-2.0.2/lib/action_controller/dispatcher.rb:115:in `dispatch' /var/lib/gems/1.8/gems/actionpack-2.0.2/lib/action_controller/dispatcher.rb:126:in `dispatch_cgi' /var/lib/gems/1.8/gems/actionpack-2.0.2/lib/action_controller/dispatcher.rb:9:in `dispatch' /var/lib/gems/1.8/gems/rails-2.0.2/lib/fcgi_handler.rb:101:in `process_request' /var/lib/gems/1.8/gems/rails-2.0.2/lib/fcgi_handler.rb:149:in `with_signal_handler' /var/lib/gems/1.8/gems/rails-2.0.2/lib/fcgi_handler.rb:99:in `process_request' /var/lib/gems/1.8/gems/rails-2.0.2/lib/fcgi_handler.rb:77:in `process_each_request' /var/lib/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:612:in `each_cgi' /var/lib/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:609:in `each' /var/lib/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:609:in `each_cgi' /var/lib/gems/1.8/gems/rails-2.0.2/lib/fcgi_handler.rb:76:in `process_each_request' /var/lib/gems/1.8/gems/rails-2.0.2/lib/fcgi_handler.rb:50:in `process!' /var/lib/gems/1.8/gems/rails-2.0.2/lib/fcgi_handler.rb:24:in `process!' /home/rails/public/dispatch.fcgi:24 ... attempted adding second root element to document Line: Position: Last 80 unconsumed characters: Internal error, sorry. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC // Konkurrenz
Marcus Wolschon schrieb: Sotware? Gibts da ein einheitliches Protokoll, wie ein Consumer-Empfänger das in einen Computer übergibt? Klar, RDS-TCM halt: http://de.wikipedia.org/wiki/Radio_Data_System Mit Plastiksoundkarten (Creative) geht das aber nicht. Brauchst schon hochwertigere, die das Ausgangssignal nicht manipulieren. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC // Konkurrenz
Andreas Pothe schrieb: TMCpro ist kostenpflichtig, ja. Allerdings einmalig pro ausgeliefertem Gerät bzw. Software vom Navihersteller, eine Mobilfunkverbindung wird nicht benötigt, da es genau wie TMC über Radiosender übertragen wird. Über wessen UKW-Frequenzen kommen die denn? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC // Konkurrenz
Tobias Wendorff: Andreas Pothe schrieb: TMCpro ist kostenpflichtig, ja. Allerdings einmalig pro ausgeliefertem Gerät bzw. Software vom Navihersteller, eine Mobilfunkverbindung wird nicht benötigt, da es genau wie TMC über Radiosender übertragen wird. Über wessen UKW-Frequenzen kommen die denn? Private Rundfunkanstalten. Ad hoc fällt mir BFBS ein, aber auch viele andere wie FFN Co. CU Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Benutzung von is_in
On Fri, Dec 26, 2008 at 12:21:05AM +0100, g.d wrote: Ja doch... Zu seiner Ortsverwaltung, zu seinem Rathaus, zu seiner UnterPräfektur (die hatte ich in der Liste vergessen), oder zu seiner Präfektur. Und in Paris auf die PolizeiPräfektur. Wenn's jedoch um die Wasser/Abwasserrechnung geht, dann geht's die Präfekturen nix an, sondern andere parallele Verwaltungen von Ortszusammenschlüssen. Und wenns um Schultransport geht, dann geht's das Département an, oder gar die Region - aber nicht die zentrale Schulverwaltung (die ûbrigens nix mit der régionalen oder départementalen Kulturverwaltung zu tun hat). Das ist hier sehrstens differenziert. Kafka ist da Kindermärchen dagegen, wie's hier läuft (oder nicht läuft)... :-( .../... Okay - also tendentiell ist es in deutschland ja so das die administrativen ebenen immer kongruent sind d.h. das die darueberliegende administrative ebene immer eine menge von darunterliegenden sind. D.h. es kann nicht sein das der Regierungsbezirk Detmold nur die haelfte des Kreises Gütersloh beinhaltet. Irgendwie hätte ich jedoch gehofft, dass die Angabe nur der nächsthöheren Hierarchie derartige Verwechslungen ausschliessen könnte, zusammen mit den geographischen Grenzen der Gemeinden und Kreise... .../... Das würde aber vollstaendiger Grenzen bedürfen. Das sind sie aber bei weitem nicht. Nö, das meinte ich nicht, sondern : Ich habe auf der Deutsche OSM-Karte mehrere residential areas angetroffen mit name:Name_der_Ortschaft, wo aber kein Node place ist. Und andererseits gibt es derartige areas mit name:Name_der_Ortschaft, wo zusätzlich auch ein Node mit name:Name_der_Ortschaft ist. Irgenwas ist da unklar, oder doppelt (Ich nuckel' zwar grad' einen guten Rosé von hier, aber ganz besoupen bin ich noch nicht... ;-) .../... Ich wuerde das nicht als notgedrungen unvollstaendig sehen. Ich habe auch schon residential areas eingetragen mit name=Siedlung Determeyer zum beispiel. Die Siedlung heisst nunmal so - Der place waere aber ein suburb=Spexard - Spexard selber besteht aber aus mehreren residential areas die nicht unbedingt eigene namen haben. Wir machen hier die Grenzen mit left und right, so etwa : boundary: administrative border_type: region left:departement: Aveyron right:departement: Gard left:region: Midi-Pyrénées right:region: Languedoc-Roussillon admin_level: 4 oder boundary: administrative border_type: departement left:departement: Gard right:departement: Hérault admin_level: 6 Aber bis jetzt sieht man die Bezeichnungen nicht auf der Karte, bloß die Grenzlinien. Nu, wird schon werden, irgendwann mal... left und right ist doof und gerade in Deutschland wieder am verschwinden. Das problem ist das ja die Kreisgrenze gleichzeitig grenze des Regierungsbezirkes, des Landes und die Bundesgrenze sein kann. Dieses heisst ja das der admin_level auf abschnitten mehrfach da sein muesste und auch left und right teilweise andere dinge benennen. D.h. in D ist dann auf dem way nur ein boundary:administrative und der rest ist auf einer relation die alle boundary elemente beinhaltet. Aber dass die Renderers auf Basis der Grenzen auch die Namen der Gemeinden anzeigen würden, daran wage ich zu zweifeln : Das wäre doppelte Anzeige, weil ja jede Gemeine bereits ihren Node mit name: hat, zuminst theoretisch, wenn wir gut gearbeitet haben. Anzeigen nicht. Das waere am node. Aber fuer die Straßensuche waere die Grenze interessant. Es kann ja in benachbarten gemeinden jeweils Straße A geben - Es kann aber sein das die naeher an dem node der Nachbargemeinde ist - Damit ist das durch distanzsuche nicht zu loesen. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC
On Fri, Dec 26, 2008 at 12:24:24AM +0100, John07 wrote: Sofern ich das richtig verstanden habe, braucht man Tabellen, um die TMC-Daten den OSM/Navigations-Daten zuzuordnen. Bei Openrouteservice ist das ja möglich, warum sollte es also nicht auch für jede andere OSM-Anwendung möglich sein bzw. wenn ORS die Daten nutzen kann/darf, warum dann nicht auch andere OSM-Anwendungen? Außerdem haben die von ORS wohl Erfahrung mit TMC in Verbindung mit OSM, daher finde ich meinen Hinweis durchaus nützlich. Die Lizenz der daten laesst das nicht zu - ausserdem wuerde es ja auch sinn machen die Daten nicht seperat in einer TAbelle zu halten sondern mit an die entsprechend gemeinten Ways in den OSM daten als tmc_id=X oder tmcpro_id=Y zu packen. Aber das erlauben eben die Urheber dieser Daten nicht. Fuer Privaten gebraucht zum rumdameln sind die zu bekommen - ebenso wie auch Luftbilder von NRW ... Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC // Konkurrenz
On Fri, Dec 26, 2008 at 07:14:34PM +0100, Tobias Wendorff wrote: Klar, RDS-TCM halt: http://de.wikipedia.org/wiki/Radio_Data_System Mit Plastiksoundkarten (Creative) geht das aber nicht. Brauchst schon hochwertigere, die das Ausgangssignal nicht manipulieren. Es gibt mit ein bischen suchen einen UKW USB Radio das die RDS Daten gleich digital an den Rechner liefert - Auch mit Treibern unter Linux. Ich habe das dingen hier schon liegen (20Euronen meine ich). Zum experimentieren fehlts mir gerade an der Zeit ... Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC // Konkurrenz
Am 26.12.08 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Marcus Wolschon schrieb: Sotware? Gibts da ein einheitliches Protokoll, wie ein Consumer-Empfänger das in einen Computer übergibt? Klar, RDS-TCM halt: http://de.wikipedia.org/wiki/Radio_Data_System Mit Plastiksoundkarten (Creative) geht das aber nicht. Brauchst schon hochwertigere, die das Ausgangssignal nicht manipulieren. Klingt jetzt nach einer Bastel-Lösung. Was gibt es, was Otto Normalverbraucher im Laden kaufen kann, wo TMC drauf steht und wie binde ich das in mein Java-Navi ein? Du erwähntest Software um RDS zu dekodieren. auch im NMEA-Stream ist nur die RDS-Kodierung mir noch unbekannt. Welche Software gibt es und wo finde ich deren Sourcecode und Dokumentation? Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC // Konkurrenz
On Fri, Dec 26, 2008 at 08:33:51PM +0100, Marcus Wolschon wrote: Klingt jetzt nach einer Bastel-Lösung. Was gibt es, was Otto Normalverbraucher im Laden kaufen kann, wo TMC drauf steht und wie binde ich das in mein Java-Navi ein? Du brauchst einen UKW Empfaenger der dir den RDS Subchannel rauswirft. Der Linux Treiber fuer das chipset hat das hier drinstehen: * Driver for USB radios for the Silicon Labs Si470x FM Radio Receivers: * - Silicon Labs USB FM Radio Reference Design * - ADS/Tech FM Radio Receiver (formerly Instant FM Music) (RDX-155-EF) Die dinger spucken gleich das RDS seperat raus und es scheint da irgendwelches standard zeugs mit video4linux zu geben. Danach brauch man nur noch einen RDS decoder der einem das TMC rausfiltert, und dann einen TMC decoder. Du erwähntest Software um RDS zu dekodieren. auch im NMEA-Stream ist nur die RDS-Kodierung mir noch unbekannt. Welche Software gibt es und wo finde ich deren Sourcecode und Dokumentation? Naja - um im NMEA das RDS zu haben muesste man ja einen kombiempfaenger GPS + UKW haben - Gibts solche devices zum mitrumschleifen so im praktischen Streichholzschachtelformat? Ich kenne so spontan nix ... Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM auf dem 25C3
Am 13.12.08 schrieb Andreas Hubel a...@saerdnaer.de: Ich habe uns mal eine Stunde reservieren lassen. Zugewiesen wurde uns Tag 1 von 19:00 bis 20:00 Uhr. Agenda Anyone? ;-) Hallo Andi. Irgendwer hat mich auf der Workshop-Seitte als Verantwortlich eingetragen und jetzt werde ich mi Anfragen zu deinem Workshop überhäuft. Da ich deinen useramen im Wiki nicht kenne, hab ich dich mal mit Realnamen eingetragen aber ohne email. Kannst du bitte deine email-Adresse oder wiki-userseite nachtragen? Danke, Marcus. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC // Konkurrenz
2008/12/26, Florian Lohoff f...@rfc822.org: On Fri, Dec 26, 2008 at 08:33:51PM +0100, Marcus Wolschon wrote: Klingt jetzt nach einer Bastel-Lösung. Was gibt es, was Otto Normalverbraucher im Laden kaufen kann, wo TMC drauf steht und wie binde ich das in mein Java-Navi ein? Du brauchst einen UKW Empfaenger der dir den RDS Subchannel rauswirft. Der Linux Treiber fuer das chipset hat das hier drinstehen: * Driver for USB radios for the Silicon Labs Si470x FM Radio Receivers: * - Silicon Labs USB FM Radio Reference Design * - ADS/Tech FM Radio Receiver (formerly Instant FM Music) (RDX-155-EF) Die dinger spucken gleich das RDS seperat raus und es scheint da irgendwelches standard zeugs mit video4linux zu geben. Danach brauch man nur noch einen RDS decoder der einem das TMC rausfiltert, und dann einen TMC decoder. Ja nach dem RDS-Decoder und TMC-decoder hab ich gefragt. WICHTIG: Wo finde ich da sourcecode davon? Weniger wichtig: Kannst du mir ein Gerät zum Kaufen zeigen? Du erwähntest Software um RDS zu dekodieren. auch im NMEA-Stream ist nur die RDS-Kodierung mir noch unbekannt. Welche Software gibt es und wo finde ich deren Sourcecode und Dokumentation? Naja - um im NMEA das RDS zu haben muesste man ja einen kombiempfaenger GPS + UKW haben - Gibts solche devices zum mitrumschleifen so im praktischen Streichholzschachtelformat? Ich kenne so spontan nix ... Ja, gibt es sogar einige. Hab ich vorhin doch sogar einen Blog-Post der das Format erklährt verlinkt. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM auf dem 25C3
Ich hab die habe die Zuständigkeitsangaben mal in Ordnung gebracht und auf der OSM Wiki Seite im Congress Wiki nen Workshop Abschnitt einfgefügt. http://events.ccc.de/congress/2008/wiki/OpenStreetMap#Workshop Ansonsten hier mal meine Benutzerseite: http://events.ccc.de/congress/2008/wiki/User:Saerdnaer Ich komm morgen einfach mal beim Stand vorbei. MfG Andi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Küstenlinienprobleme auf Kreta
Chris66 schrieb: Hi, also in Mapnik sieht es doch gut aus!? Ab Zoomstufe 9 und kleiner ist immernoch etwas faul. Beste Grüße, Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Papierkarte (DIN A0 oder ähnliche Größe) drucken
Wolfgang W. Wasserburger schrieb: ;-) hpgl2dxf haben wir früher mal verwendet -googlen reicht vielleicht Das war noch zu Stiftzeiten, oder? den hp 650C dürfte es schon gegeben haben ;-) CU W ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM auf dem 25C3
User:Leo Wenn du hier mitliest, ich fahre morgen 07:00 auch von Rostock (Reutershagen) ab. +49 177/6272871 Einen Platz hab ich frei. Am 26.12.08 schrieb Andreas Hubel a...@saerdnaer.de: Ich hab die habe die Zuständigkeitsangaben mal in Ordnung gebracht und auf der OSM Wiki Seite im Congress Wiki nen Workshop Abschnitt einfgefügt. http://events.ccc.de/congress/2008/wiki/OpenStreetMap#Workshop Ansonsten hier mal meine Benutzerseite: http://events.ccc.de/congress/2008/wiki/User:Saerdnaer Ich komm morgen einfach mal beim Stand vorbei. MfG Andi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC // Konkurrenz
On Fri, Dec 26, 2008 at 09:53:03PM +0100, Marcus Wolschon wrote: * Driver for USB radios for the Silicon Labs Si470x FM Radio Receivers: * - Silicon Labs USB FM Radio Reference Design * - ADS/Tech FM Radio Receiver (formerly Instant FM Music) (RDX-155-EF) Die dinger spucken gleich das RDS seperat raus und es scheint da irgendwelches standard zeugs mit video4linux zu geben. Danach brauch man nur noch einen RDS decoder der einem das TMC rausfiltert, und dann einen TMC decoder. Ja nach dem RDS-Decoder und TMC-decoder hab ich gefragt. WICHTIG: Wo finde ich da sourcecode davon? Ich darf dir helfen google zu bedienen - rds linux 2. hit: http://rdsd.berlios.de/ Weniger wichtig: Kannst du mir ein Gerät zum Kaufen zeigen? Habe ich alles mit google geklaert - Ich habe auf amazon so nen Instant Music gefunden ... Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Hallo Andererseits kommt Weg drehen sowieso selten vor, insofern ist es vermutlich auch nicht sonderlich schlimm wenn man da gefragt wird. Am häufigsten kommt es wahrscheinlich beim Verbinden von Wegen vor, da sollte dann automatisch angepaßt werden, dreht man absichtlich sollte man gefragt werden. Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Rueckhaltebecken / Ueberschwemmungsflaeche
Moin moin Hatten wir schon mal das Thema Rueckhaltebecken / Ausgleichs- / Ueberschwemmungsflaechen? Ein Gebiet/Senke, das/die meist nur wenig bis gar kein Wasser enthaelt, evt. von einem Gewaesser durchflossen wird, und nur zu bestimmten Zeiten (starke Regenfaelle, Schneeschmelze usw.) mit Wasser gefuellt ist, so dass ein See entsteht. Diese Gebiete sind meistens mit einem Damm begrenzt. Wie mappen wir sowas? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC
Marcus Wolschon schrieb: Am 26.12.08 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Interessant: Der 1. Google-Eintrag ist mit dem Download-Link der Liste verlinkt, ohne dass man irgendwas bestellen oder angeben muss. Durch die richtigen Stichwörter findet man die Liste auch über die offizielle Suchfuntkion von BASt.de :-) Die Tags der Liste sind ziemlich ähnlich zu unseren :- Cool. Hat noch wer eine Beschreibung des eigentlichen Protokolls und wie das bei geeigneten GPS-Empfängern im NMEA-Datenstrom eingebettet ist? Wäre toll das implementieren zu können. Zu Java und TMC finde ich nur ein leeres Projekt ohne jeden Code. Kennt jemand verständlich dokumentierte Implementierunen des Protokolls? Die Rechte an dem Protokoll hat soweit ich weiss GNS und hatte damit wohl auch schon einige Rechtsstreite angefochten (gegen Mitbewerber der GPS-TMC-Empfänger). Ist schon ein paar Tage her, wie die aktuelle Rechtlage aussieht weiss ich nicht. Technisch werden da einfach ein paar Binärdaten zwischen den NMEA-Protokollen durchgeschoben. Mit NMEA hat TMC nichts zu tun, man nutzt einfach nur aus das NMEA feste Protokollvorgaben hat so dass diese Binärdaten herausgefilter und separat verarbeitet werden können. Sinn des ganzen ist naviseitig mit einer einzigen UART (RS232, teilweise auch aus USB umgesetzt) auszukommen. Ist für die OSM-Umsetzung aber erstmal alles unnötig, da kann man die Daten auch auf anderen Wegen zuführen bevor man damit ins Feld geht. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC // Konkurrenz
Tobias Wendorff schrieb: Marcus Wolschon schrieb: Sotware? Gibts da ein einheitliches Protokoll, wie ein Consumer-Empfänger das in einen Computer übergibt? Klar, RDS-TCM halt: Nee, das gibt es nicht bei Tchibo und heisst daher immer noch TMC wie Traffic Message Channel... ;-) TMC ist dabei nur ein Unterprotokoll von RDS. RDS ging schon mit dem ATARI ST zu dekodieren, war ein IC am Druckerport der mit dem Radio verbunden werden musste - heute geht es wohl ganz in Software wenn das Trägersignal Radioseitig nicht ausgefiltert wurde. http://de.wikipedia.org/wiki/Radio_Data_System Mit Plastiksoundkarten (Creative) geht das aber nicht. Brauchst schon hochwertigere, die das Ausgangssignal nicht manipulieren. Naja, ein Radiosignal ist nicht unbedingt hochwertig wenn es das RDS-Signal mit ausgibt da dies ein Störsignal zur Musik ist - können die meisten aber eh nicht hören. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Gewässern
Nop schrieb: Wasser is Wasser und immer natural. Wie die Ansammlung von Wasser zustandekommt, ist doch in erster Linie irrelevant. Relevant ist für den Renderer, daß er da Blau hinpappt, und für den Router (zumindest für die Straßen/Wege-gebundenen), daß es ein Hindernis ist. Irgendwie scheint mir das aber reichlich inkonsequent. Bei Wäldern wird großer Wert darauf gelegt, daß die Bäume nicht natural=wood sondern landuse=forest sind. Bei Wasser sollen Fischteiche und Stauseen als water=natural gelten? Wäre halt langsam Zeit eine hierachie aufzustellen und Ordnung ins System zubringen - Oberbegriff water damit der einfachste Renderer überall Wasser einzeichnen kann wo Wasser ist ohne alle Unterarten kennen zu müssen. Der bessere Rendere kann dann in beliebigen Schattirungen unterscheiden welche Art von Wasser es sich handelt... Garry. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC // Konkurrenz
Marcus Wolschon schrieb: Weniger wichtig: Kannst du mir ein Gerät zum Kaufen zeigen? Probiers mal hier: http://www.gns-gmbh.com/index.php?id=78 Oder was meinst Du? Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC // Konkurrenz
Garry schrieb: Dann wird es Zeit ein OSM-TMC aufzubauen - eigentlich müssten wir das viel genauer adressierbar hinbekommen in dem wir jeden Node als Adresse zulassen... Dann brauchst Du aber mehrere Institutionen, die mit uns zusammen arbeiten. Zum einen natürlich Radiosender, die unsere Daten aussenden oder ein Modell über UMTS oder W-LAN. Letzteres würde aber eine große Verbreitung von W-Lan fähigen Geräten voraussetzen, die dann jeweils die Daten weiterleiten (wie bei der Flüsterpost). Dann brauchst Du natürlich noch Verkehrsdaten. Da könnte man entweder wieder mit Radiosendern zusammenarbeiten oder man stattet die Geräte mit einer Software aus um selbst Meldungen einzutragen. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC // Konkurrenz
André Reichelt schrieb: Garry schrieb: Dann wird es Zeit ein OSM-TMC aufzubauen - eigentlich müssten wir das viel genauer adressierbar hinbekommen in dem wir jeden Node als Adresse zulassen... Dann brauchst Du aber mehrere Institutionen, die mit uns zusammen arbeiten. Zum einen natürlich Radiosender, die unsere Daten aussenden oder ein Modell über UMTS oder W-LAN. Letzteres würde aber eine große Verbreitung von W-Lan fähigen Geräten voraussetzen, die dann jeweils die Daten weiterleiten (wie bei der Flüsterpost). Dann brauchst Du natürlich noch Verkehrsdaten. Da könnte man entweder wieder mit Radiosendern zusammenarbeiten oder man stattet die Geräte mit einer Software aus um selbst Meldungen einzutragen. Wir brauen nur Geräte mit GPRS und GPS Verbindung, etwas Software und genügend Teilnehmer... Ein Gateway zu einer TMC-Schleuder wäre für den Anfang natürlich hilfreich um von Anfang an Funktionsfähig zu sein. Garry Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC // Konkurrenz
2008/12/26, Florian Lohoff f...@rfc822.org: On Fri, Dec 26, 2008 at 09:53:03PM +0100, Marcus Wolschon wrote: * Driver for USB radios for the Silicon Labs Si470x FM Radio Receivers: * - Silicon Labs USB FM Radio Reference Design * - ADS/Tech FM Radio Receiver (formerly Instant FM Music) (RDX-155-EF) Die dinger spucken gleich das RDS seperat raus und es scheint da irgendwelches standard zeugs mit video4linux zu geben. Danach brauch man nur noch einen RDS decoder der einem das TMC rausfiltert, und dann einen TMC decoder. Ja nach dem RDS-Decoder und TMC-decoder hab ich gefragt. WICHTIG: Wo finde ich da sourcecode davon? Ich darf dir helfen google zu bedienen - rds linux 2. hit: http://rdsd.berlios.de/ rdsd ist rdsd, librds, and rdsquery are in alpha state now und seit dem 1.1.2006 mit Version 0.0.1 hat sich da nichts getan. Das scheint nichts funktionierendes zu sein. jTMC gibts auch, hat nicht eine Zeile Sourcecode. Ich suche nicht zum ersten Mal wegen dem Thema und habe nie was funktionierendes gefunden, was ich in mein Navi einbauen könnte. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC
Am 27.12.08 schrieb Garry garr...@gmx.de: Cool. Hat noch wer eine Beschreibung des eigentlichen Protokolls und wie das bei geeigneten GPS-Empfängern im NMEA-Datenstrom eingebettet ist? Wäre toll das implementieren zu können. Zu Java und TMC finde ich nur ein leeres Projekt ohne jeden Code. Kennt jemand verständlich dokumentierte Implementierunen des Protokolls? Die Rechte an dem Protokoll hat soweit ich weiss GNS und hatte damit wohl auch schon einige Rechtsstreite angefochten (gegen Mitbewerber der GPS-TMC-Empfänger). Ist schon ein paar Tage her, wie die aktuelle Rechtlage aussieht weiss ich nicht. Technisch werden da einfach ein paar Binärdaten zwischen den NMEA-Protokollen durchgeschoben. Mit NMEA hat TMC nichts zu tun, man nutzt einfach nur aus das NMEA feste Protokollvorgaben hat so dass diese Binärdaten herausgefilter und separat verarbeitet werden können. Sinn des ganzen ist naviseitig mit einer einzigen UART (RS232, teilweise auch aus USB umgesetzt) auszukommen. Ist für die OSM-Umsetzung aber erstmal alles unnötig, da kann man die Daten auch auf anderen Wegen zuführen bevor man damit ins Feld geht. Genau das erscheint mir aber als die sinnvollste und natürlichste Form TMC zu nutzen. Außerdem wird die Lizenz wohl kaum erlauben genau die TMC-Daten auf anderem Wege wieder zu veröffentlichen. Wie das mit dem Einbetten funktioniert haben wir schon im Detail hier. Was jetzt noch fehlt ist ein Stück Sourcecode oder eine Beschreibung wie man RDS im allgemeinen und TMC im Speziellen auseinander nimmt um zu Event x StartOrt x EndOrt oder Event x Ort -Tupeln zu kommen. Wenn jemand da etwas hat, baue ich das gerne bei mir ein und stelle den Sourcecode und eine Dokumentation öffentlich. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Plaedoyer fuer Nick ohne Realnamen
grungelborz grungelb...@arcor.de writes: Ich werde beim Nick ohne echten Namen bleiben, da diese Mailingliste im Google-Index auftaucht. Ansonsten ist es z.B. bei jeder Bewerbung dem Arbeitgeber möglich meine Mailinglisten/Forums-Artikel zu lesen. Wenn du keinen realnamen verwendest, ist es dem arbeitgeber nicht möglich, deine artikel zu lesen. Offensichtlich bist du jemand, der sich nicht unter menschen traut, der menschen nichts zu sagen hat, der in der modernen welt nicht kommunizieren kann. Das könnte auch zu denken geben. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Frazioni
Elena of Valhalla ha scritto: 2008/12/24 Carlo Stemberger carlo.stember...@gmail.com: In estrema sintesi (ma, ripeto, è quello che è scritto sul wiki...): 1) la frazione è urbanisticamente autonoma rispetto al resto del comune? (ci sono campi/boschi tutt'attorno?) No --- suburb --- fine anche se il comune e` un village? nel caso il rendering e` sbagliato, perche' da loro piu` importanza di quanto non ne dia al comune principale Purtroppo questa è la soluzione a cui eravamo arrivati, che è coerente ma effettivamente non ancora perfetta: manca proprio un tag per indicare le frazioni di frazioni e situazioni analoghe, visto che anche avere un'infinità di village tutti renderizzati allo stesso modo non è il massimo. -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\` /\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] openlayers+osm problemi tile
vorrei aggiungere il layer di OpenStreetMap in Openlayers, non da
nessun errore ma quando provo a visualizzare il layer di OSM si vedono
tutte le tile rose, penso sia un problema di proiezione, infatti tutti
gli altri layer sono in WGS84 mentre quello di OSM è in epsg:900913,
ho provato alcune soluzioni ma non capisco come risolverlo, il codice
originale lo potete trovare qui[1], io ho aggiunto queste righe
var mapnik = new OpenLayers.Layer.TMS(OpenStreetMap
(Mapnik),http://tile.openstreetmap.org/,{layers:
'basic'},{SphericalMercator: 'Two transforms declared'},{type: 'png'},
{getURL: 'osm_getTileURL'}, {'attribution': 'a
href=http://www.openstreetmap.org/;OpenStreetMap/a'});
map.addLayer(mapnik);
ciao e grazie
Luca
[1]http://www.lucadelu.org/bmp_mappa.html
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Stradario (era: Intersezione tra strade e confini)
On Wed, Dec 24, 2008 at 6:20 PM, Carlo Stemberger carlo.stember...@gmail.com wrote: A questo proposito, qualcuno per caso a voglia di dilettarsi (profittando di queste vacanze) a scrivere uno script per estrarre lo stradario di un comune qualsiasi? Dovrebbe essere abbastanza divertente, l'applicazione è senz'altro molto utile e, in teoria, dovrebbe essere possibile realizzarla, da quando abbiamo i confini. uno dei passaggi potrebbe essere quelo di usare questo programma http://lists.openstreetmap.org/pipermail/dev/2008-November/012561.html per dare in pasto la forma del confine ad osmosis ed estrarre il planet del comune. dopodiche' estrarre lo stradario mi piacerebbe molto mettere a disposizione i planetini delle regioni e/o province. -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-es] felices fiestas
a todos. cuidadín con el gps y las copitas. que salen unas trazas de mierda. sergio Si bebes, no mapees. Gobierno de España. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] felices fiestas
Un día de éstos tengo que escribir a los reyes magos para que me cuenten su implementación del Travelling Salesman... porque para recorrer medio mundo en una sola noche con tres camellos, ya puede ser óptima. Felices fiestas a todos, -- -- Iván Sánchez Ortega i...@sanchezortega.es Never laugh at live dragons. -- Bilbo Baggins [J.R.R. Tolkien, The Hobbit] signature.asc Description: This is a digitally signed message part. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
[Talk-es] El Escorial
Gracias por tu email, Jorge. Personalmente no soy partidario de responder a los mensajes soeces con largas disquisiciones. Como suele decirse, ese chico 'se retrata a sí mismo'. Saludos Lucas Martín, no participo mucho en esta lista porque francamente no dispongo de demasiado tiempo para OSM. Aún así la sigo desde hace dos años y conozco a varias de las personas que aquí participan. He de decir que me ha sorprendido bastante el tono de tu mensaje y no me puedo resistir a contestar por alusiones tanto como trabajador de Prodevelop como miembro del proyecto gvSIG. También diré que hasta donde he seguido la conversación no le encuentro mucho sentido a tu reacción a un simple comentario de Juan Lucas respecto a la oferta de trabajo, salvo que se deba a temas externos. 2008/12/23 Martin (OPENGeoMap) martin en opengeomap.org http://lists.openstreetmap.org/listinfo/talk-es : venao+venao=venao al cuadrado. A ver mandril que nosotros llevemos 30 años trabajando en el escorial es directamente proporcional a que la nasa lleve 40 años en el escorial: http://www.elmundo.es/elmundo/2004/02/13/ciencia/1076701101.html Nuestro modelo de negocios y de hacer las cosas es diferente a vosotros y diferenciamos horas de trabajo, la amistad y ocio claramente. Vosotros sois una colsultora carnicera que ha recibido el software libre por via anal y lo exporta por via oral. Sois los becarios profesionales de IVER que realizo el 99% de gvsig y una subconsultora facilona y resultona. Lo vuestro chicos es como si el gobierno de los EEUU contrata a dedo a una consultora incompetente para hace un programa y le llama (red-hat u suse) y luego esa consultora ficticia se dedica a voicotear y amenazar a las demas empresas de software libre. De las descalificaciones gratuitas no diré nada, salvo que tengo un tío carnicero que nada tiene que ver con el desarrollo de proyectos de software. De la segunda frase te diré que en Prodevelop hay becarios, casi todos se acaban quedando a trabajar con nosotros porque realmente es un sito en el da gusto trabajar, si no fuera así no la defendería públicamente (no voy a recibir ni un bote de olivas por este correo). Cuando tengas pruebas de que Prodevelop boicotea algo vete a un juzgado, no hagas demagogia de garrafón. Luego hablaré más de esto. A vosotros os falta talento e inteligencia para crear nada más que las formulitas que encontrais en google. Por eso os cagais y haceis intertar ver a todo el mundo que programas como KOSMO creados por métodos de software libre real y gente que se lo curra de verdad como ha quedado claro en la diputacion de alava este año. Para vosotros sólo gvsig es software libre porque sois unos cagaos e incompetentes. http://www.opengis.es/ Perdona, en el caso concreto de Juan Lucas, es uno de los desarrolladores con más talento que he conocido nunca. Por otro lado Prodevelop cuenta con unos cuantos ingenieros en geodesia y cartografía, que no se van a google a buscar formulitas sino a bonitos libros como todo hijo de vecino (¿o te sabes la fórmula de vicenty de memoria?). De kosmo no diré nada, pero de gvSIG sí. gvSIG es la respuesta de una administración pública a la falta de un SIG de escritorio competente en 2003/2004. Por entonces ni OpenJUMP ni GRASS cumplían con los requisitos impuestos por los usuarios de la generalitat por razones diversas que no vienen al caso. Así que se decidió resolver SU problema iniciando un desarrollo. Que se podía haber hecho otra cosa, pues claro, pero es fácil criticar a toro pasado. Pero gvSIG es sólo una pieza de un proyecto de migración mucho más amplio[1]. En la conselleria han migrado muchas de sus aplicaciones a PHP, PostgreSQL, OpenLDAP, etc etc Y por supuesto en el área de SIG tienen MapServer, GeoServer, Deegree y GeoNetwork.
Re: [Talk-es] El Escorial
Hola: Pido miles de disculpas a todos los usuarios. Creo que he dicho muchas tonterias porque quizás me he sentido ofendido en algún momento y mi respuesta creo que ha sido totalmente desproporcionada como jorge muy bien ha dicho. Sólo pido que nos respetemos y nos divertamos juntos en esta lista que creo que a todos nos une. Yo seguiré en está lista para aprender de todos vosotros y para seguir pasando ratos divertidos. Un saludo, ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
[Talk-es] Traducción de JOSM en Launchpad
Hola a todos, Haciendo proselitismo de OSM me encuentro que hay gente interesada pero que se vuelven locos con el JOSM (reconozcamos que no es un programa fcil de coger al principio) y el tema de que no est traducido a nuestro idioma no hace ms que echarles para atrs. Para que esto no fuese escusa me he puesto a colaborar en la traduccin del programa en Launchpad [1] de nuevo (hace tiempo varios logramos traducir JOSM pero no se que pas al final). El caso es que he vuelto a la carga, intentando traducir las cadenas que quedan y as por lo menos llegar al 30% para que el espaol puedan ser aadido [2]. Todo esto para pediros a ver si algn alma caritativa nos echa una mano en Launchpad y conseguimos por lo menos llegar a ese porcentaje, porque la diferencia con otros idiomas es significativa. Saludos, Emilio [1] https://translations.launchpad.net/josm/trunk/+pots/keys [2] http://www.mail-archive.com/josm-...@openstreetmap.org/msg01471.html ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
[Talk-at] Straßennamen
Hi, amtlich (und laut Duden) schreibt man eigentlich: Friedrich-Wilhelm-Raiffeisen-Platz AL hat in seiner Liste: Friedrich Wilhelm Raiffeisen Platz Mir ist beides recht, ich finde aber, das sollte möglichst einheitlich sein Was meint Ihr? lg W. PS: Kirchdorf läuft gerade ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] KI
Kirchdorf ist importiert; wenn es Probleme gibt lieber zuerst melden und nix ändern, zumindest die letzte Straße ist aber da und es wurde kein Fehler gemeldet ;-) lg Wolfgang ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] GM restliche Straßen
... mit einer Ausnahme konnten diese leider nicht nachimportiert werden, weil offensichtlich mittlerweile Nodes weg sind, die ich im Update noch nicht habe. Sobald dieses da ist, probiere ich's noch mal. lg Wolfgang ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-ca] Ice Roads
On Thu, Dec 25, 2008 at 8:15 PM, Richard Degelder rtdegel...@gmail.com wrote: As one of those southerners that is going to be puzzled when I see a roadway that goes from land over water without a bridge or ferry, and not using a ford either, I have one question. Do the ice roads generally go in the same place each year or do they vary in location on the lake from one year to another? At least I will know to look for restrictions, which will note that the road is only open during the winter, when I see these roads. Richard, I think this is a perfect question for discussion on the reflector, and probably for inclusion on the Wiki as well. Generally the ice roads follow the same path every season. As some of the roads consist of sections over land, as well as sections over water, there is a need to follow the same track. Sections across land will have obstacles such as rocks and trees removed, which means that the transition point from land to water will always be in the same place. The section across water (or more correctly, ice) could vary slightly from year to year, or even during the road's open season due to holes needing to be detoured around. Occasionally vehicles will break through the ice, and ice road will need to be moved to a new location. Ice bridges are also used to allow traffic to move across bodies of water during the winter. During the summer months, at some locations, ferries run moving traffic across the river or lake. For a time in the fall during freeze up, and in the spring during break up neither ferries for the ice bridge can move vehicular traffic across the water. Here's how Google Maps depicts a crossing on the Liard River near Fort Simpson. http://maps.google.com/?ie=UTF8ll=61.740061,-121.220741spn=0.046653,0.154495z=13 Wikipedia describes ice roads nicely as well. The NWT government maintains a live website which allows travellers to check on the condition of the ice roads. There are a number of interesting website links off of these pages. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] GeoBase to OSM attribute mapping.
Just looking at some attributes... The alleyway/lane is currently mapped as highway:service. I would suggest that highway:service is more appropriate. Here's the description for a sevice road: Generally for access to a building, motorway service station, beach, campsite, industrial estate, business park, etc.. This is also commonly used for access to parking and trash collection. Sometimes called an alley, particularly in the US. Local/unknown is currently mapped to highway:service. This should probably be highway:road. where that is described as: Road with an unknown classification. This tag should be used temporarily until the road has been properly surveyed. Once it is surveyed the highway tag should be changed to record the appropriate classification. Rapid Transit is currently mapped to highway:bus_guideway. I'm thinking railway:light_rail, at least in Edmonton, our rapid transit system is a light rail transit system. Perhaps other areas of Canada have a rubber tire based guided transit system. When working on another GeoBase to public map project, I ended up making Freeway and Expressway map to the same road type, with Highway mapped to the next lower level. There's no mapping to highway:trunk. I'd have to dig into the NRN deeper to look at sample roads and tags again, but I think our top level roads would map to highway:motorway. This would include such entities as the Queen Elizabeth II Highway (#2) between Edmonton and Calgary, although in some areas the restricted access limits don't quite apply. In Alberta, we haven't tagged anything as highway:motorway. Our top level tag is highway:trunk. This GeoBase/OSM project could work to unify the tagging across the country! What about Freeway - highway:motorway, Expressway - highway:trunk, Highway - highway:primary? James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] geobase2osm
Jason, I looked up your script geobase2osm and noted several things. The README states that this is not ready for production work yet which is fine. But at the same time I also noticed that at no point have you given a license to the script, neither in the README nor within the script itself. Also, there is not a copyright statement anywhere, and you deserve the right to receive credit for your work, nor a way to contact you if someone does have some suggestions, or better yet code, for improving the script. Would you be willing to add a license statement, preferably for an Open Source license, to your script? Doing so will allow others to be able to use, and modify if necessary, your script for their work in migrating the data from GeoBase to OSM. It may also encourage others to contribute to the script to help you develop it further and to get it ready for production use. Adding some way of contacting you, preferably within one of the comment statements within the script, would also be appreciated. Thank you, Richard Degelder ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] geobase2osm
Richard Degelder wrote: Jason, I looked up your script geobase2osm and noted several things. The README states that this is not ready for production work yet which is fine. But at the same time I also noticed that at no point have you given a license to the script, neither in the README nor within the script itself. Also, there is not a copyright statement anywhere, and you deserve the right to receive credit for your work, nor a way to contact you if someone does have some suggestions, or better yet code, for improving the script. Would you be willing to add a license statement, preferably for an Open Source license, to your script? Doing so will allow others to be able to use, and modify if necessary, your script for their work in migrating the data from GeoBase to OSM. It may also encourage others to contribute to the script to help you develop it further and to get it ready for production use. Adding some way of contacting you, preferably within one of the comment statements within the script, would also be appreciated. Thank you, Richard Degelder Richard: I will be adding that information soon. I've got a couple patches that people have sent me, including a fairly large one that Steve Singer did to fix the reprojection of the data that I will be committing in the next few days. -Jason Reid ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-us] US Route Tagging With Relations
Personally, I think putting the US: in front of state routes is going to get confusing. People are oing to think they're looking at US routes and not state routes. Second, some significant caution will be needed with adding signs. Some signs (mainly toll roads opened after 1989) are copyrighted and could not be used under any circumstances. See the Wikipedia page where this was discussed: http://en.wikipedia.org/wiki/Wikipedia:Copyright_on_highway_shields 25or6to4 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
