[Talk-transit] a little idea for new public transport shema
Hi, i have read some mails about problems with too much relations for public transport lines. Also I see a problem with stoppoints and platforms specaly by bus and tram lines. And maintain with other Data maybe not very easy esp. GTFS data. In most systems I know there are stored segemts between two stops and these segments together are a lineroute. These segemnts, I think, have some advantages: - only one relation for each direction on the between most stops - no need for stoppoints because the relation starts and ends at a stoppoint near the platform - easy to ad new lines because the can use existing segments - most flexibility because small segments ( this may be a disadvantage too because it need much work at the start) regards Jan --- Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! Rundum glücklich mit freenetMail___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] a little idea for new public transport shema
Since I'm the one who proposed this initially, I'm going to add some more detail. Stops on opposing sides of a street are hardly ever, exactly opposite one another, so usually there are 2 stop_positions. This means there will usually be pairs of route_segment relations, one for each direction. For stops near a crossing, where some bus lines go to the right, others straight on and others to the left, the (high)way up to the crossing can become member of up to 6 relations. But that's still better than to have them as members of all route relations and their variations for a line. Having a route_segment for each sequence of highways between two stops, is a possibility, but there I don't see a reason why a segment couldn't describe how the bus goes from A to E passing B, C and D. Unfortunately, one of the advantages of the Oxomoa scheme (being able to oversee immediately that a route is continuous in the relation editor) would be lost with the use of subrelations. This can be fixed, given support is programmed for it in the relation editor (thinking mostly of JOSM here). The biggest advantage is that now it's the route_segments wich become broken instead of. It's a lot easier to fix those segments once instead of fixing tens of route relations which would otherwise be present on those highways. Lastly I want to add that in some cases (around bus stations which are mapped in full detail for example), there would still be a need to add (high)ways to the route relations themselves in some cases. Polyglot 2013/12/26 v...@freenet.de Hi, i have read some mails about problems with too much relations for public transport lines. Also I see a problem with stoppoints and platforms specaly by bus and tram lines. And maintain with other Data maybe not very easy esp. GTFS data. In most systems I know there are stored segemts between two stops and these segments together are a lineroute. These segemnts, I think, have some advantages: - only one relation for each direction on the between most stops - no need for stoppoints because the relation starts and ends at a stoppoint near the platform - easy to ad new lines because the can use existing segments - most flexibility because small segments ( this may be a disadvantage too because it need much work at the start) regards Jan --- Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! Rundum glücklich mit freenetMail http://email.freenet.de/basic/Informationen ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] a little idea for new public transport shema
Hi, I think there are two advantages if you use segments from one to the next step only. The first is you can use the segements later for routes that don´t fit in the hole segment. If the bus run form A to D and than to F instead of E. Now you have two segments for almost the same way between A and D or you change all routes using the segment A to E. And the secound one is that you can find the exakt stop position as start or end of a segment without any further tags for this points. And last but not least I think this shema would better fit into other standards like GTFS or HAFAS and so on. regards Jan -Ursprüngliche Nachricht- Von: Jo [winfi...@gmail.com] Gesendet: Do. 26.12.2013 17:04 An: Public transport/transit/shared taxi related topics [talk-transit@openstreetmap.org] Betreff: Re: [Talk-transit] a little idea for new public transport shema Since I'm the one who proposed this initially, I'm going to add some more detail. Stops on opposing sides of a street are hardly ever, exactly opposite one another, so usually there are 2 stop_positions. This means there will usually be pairs of route_segment relations, one for each direction. For stops near a crossing, where some bus lines go to the right, others straight on and others to the left, the (high)way up to the crossing can become member of up to 6 relations. But that's still better than to have them as members of all route relations and their variations for a line. Having a route_segment for each sequence of highways between two stops, is a possibility, but there I don't see a reason why a segment couldn't describe how the bus goes from A to E passing B, C and D. Unfortunately, one of the advantages of the Oxomoa scheme (being able to oversee immediately that a route is continuous in the relation editor) would be lost with the use of subrelations. This can be fixed, given support is programmed for it in the relation editor (thinking mostly of JOSM here). The biggest advantage is that now it's the route_segments wich become broken instead of. It's a lot easier to fix those segments once instead of fixing tens of route relations which would otherwise be present on those highways. Lastly I want to add that in some cases (around bus stations which are mapped in full detail for example), there would still be a need to add (high)ways to the route relations themselves in some cases.Polyglot 2013/12/26 v...@freenet.de Hi, i have read some mails about problems with too much relations for public transport lines. Also I see a problem with stoppoints and platforms specaly by bus and tram lines. And maintain with other Data maybe not very easy esp. GTFS data. In most systems I know there are stored segemts between two stops and these segments together are a lineroute. These segemnts, I think, have some advantages: - only one relation for each direction on the between most stops - no need for stoppoints because the relation starts and ends at a stoppoint near the platform - easy to ad new lines because the can use existing segments - most flexibility because small segments ( this may be a disadvantage too because it need much work at the start) regards Jan --- Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! Rundum glücklich mit freenetMail ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit -Ursprüngliche Nachricht Ende- --- Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! Rundum glücklich mit freenetMail___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
[OSM-talk] Cyprous - postal codes
Hi Everybody, I manage to get a list of Cyprus postal codes from Cyprus Postal Service both in Greek and in English (as separate files). I wrote some python scripts to match the Greek and the English name of the streets and mapped them on to OSM (some of them). I am in the process of creating a script to upload the result (only manually confirmed mappings for now approximately 500 roads) and I would like to ask a few questions. Is anyone responsible for this area that I should first coordinate with? Is the correct postcode tag for a way postal_code? There shouldn't be any copyright issue with the data since Cyprus Postal Service is a government organization and the data should be public but just in case I should ask. Does anyone know or has attempted the same thing in a similar situation? I know i can put name:el and name:en as tags but what the name tag should be for a way? Greek, English and Turkish are the official languages. Thank you. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cyprous - postal codes
On Thu, Dec 26, 2013 at 7:18 AM, TDTwister Gmail tdtwiste...@gmail.com wrote: Hi Everybody, I manage to get a list of Cyprus postal codes from Cyprus Postal Service both in Greek and in English (as separate files). I wrote some python scripts to match the Greek and the English name of the streets and mapped them on to OSM (some of them). I am in the process of creating a script to upload the result (only manually confirmed mappings for now approximately 500 roads) and I would like to ask a few questions. [ ... ] Hi, Your enthusiasm and interest are welcome! Beware that importing data from other sources is a highly contentious issue in OpenStreetMap. Please read, understand and follow all of the steps in the import guidelines and related pages on the wiki before you continue. http://wiki.openstreetmap.org/wiki/Import ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cyprous - postal codes
I don't think postcodes should go on roads. Either you add them addresses or buildings as addr:postcode=.. Or you create a boundary (relation): http://www.openstreetmap.org/relation/3379414/history#map=13/50.8208/4.3755 boundary=postal_code You should indeed first discuss this on the import list as well and there they will tell you to discuss it with the local community... Maybe you can find some contributors in the history of objects to consult with? Jo 2013/12/26 TDTwister Gmail tdtwiste...@gmail.com Hi Everybody, I manage to get a list of Cyprus postal codes from Cyprus Postal Service both in Greek and in English (as separate files). I wrote some python scripts to match the Greek and the English name of the streets and mapped them on to OSM (some of them). I am in the process of creating a script to upload the result (only manually confirmed mappings for now approximately 500 roads) and I would like to ask a few questions. Is anyone responsible for this area that I should first coordinate with? Is the correct postcode tag for a way postal_code? There shouldn't be any copyright issue with the data since Cyprus Postal Service is a government organization and the data should be public but just in case I should ask. Does anyone know or has attempted the same thing in a similar situation? I know i can put name:el and name:en as tags but what the name tag should be for a way? Greek, English and Turkish are the official languages. Thank you. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM in NewScientist
OSM made it into the NewScientists 2013 review: A year in technologyhttp://www.newscientist.com/article/dn24776-2013-review-the-year-in-technology.html#.Ury7uLRFUhF (citizen mappers fill gaps in maps http://Citizen cartographers fill the gaps in maps) I think I already posted the article when it was published but I'm impressed the it has been selected for the 2013 review. Thank you all for your efforts and keep up the good work. Even if there are still a few days till new year I want to wish everyone a mappy year 2014 ;) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] [Rio de Janeiro] Mapas do Tracksource para conflação
Fernando, obrigado pela explicação detalhada, mas vou gardar o e-mail para futura referência. Já estou ocupado dando atenção ao PFM2OSM para que ele produza bons mapas. Não poderei estudar o processo de conflação agora. O que posso fazer é disponibilizar o OSM dos mapas para que as pessoas julguem seu conteúdo e sua fonte e optem pela melhor forma de aproveitar esses dados. []s PC Em 25 de dezembro de 2013 17:41, Fernando Trebien fernando.treb...@gmail.com escreveu: Paulo, Enquanto o pessoal do RJ não responde (podem estar aproveitando o feriado :D), se você quiser ir lendo sobre o assunto, sugiro este link: http://wiki.openstreetmap.org/wiki/Conflation Eles sugerem o uso de uma ferramenta (o RoadMatcher) que eu nunca usei, não sei se é rápida e/ou prática. Talvez você queira testá-la. O que eu já usei (em pequenas áreas) foi o plugin conflation do JOSM. Ele funciona melhor com Java 1.6 (no 1.7 dá vários NullPointerException em momentos diferentes). Basicamente, o plugin faz uma análise topológica e de proximidade entre nós e/ou vias (mas não ambos). Com esse plugin, você estaria fazendo uma conflação de vias para as ruas vindas dos seus dados. Para os POIs, como sei que seu conversor transforma em pontos no OSM, talvez seja necessário fazer uma conflação manual (muitos deles estão mapeados como áreas, daí o plugin não reconheceria a semelhança entre os dois tipos de objetos geométricos). Você pode fazer as duas etapas em momentos diferentes, e com changesets diferentes. Sabendo que o Rio está bem completo e que veio da mesma fonte que os seus dados, acredito que a conflação de vias serviria na verdade para excluir as ruas que já existem no OSM e presentes no seu conjunto de dados e deixar apenas aquilo que não existe no OSM ainda - ruas novas, e todos os interpoladores de endereço (há alguns no OSM, mas poucos). Se você achar a conflação muito complicada (e é um pouco), talvez você possa só importar os interpoladores. Os POIs e as ruas que faltam as pessoas (ou você, se tiver tempo) poderiam ir importando aos poucos manualmente. Uma forma de fazer esse último passo manualmente é habilitar a camada OpenStreetMap (Mapnik) no JOSM e fazer uma comparação visual. Por que eu sugiro isso: a conflação só dá um resultado confiável quando as ruas estão particionadas aproximadamente nos mesmos pontos em ambos os conjuntos. Verificar essa propriedade provavelmente daria quase tanto trabalho quando fazer a conflação manualmente. No caso da importação citada nesse artigo feita no Canadá, eles podem ter entrado no seguinte acordo (que poderia ser feito aqui também, mas precisamos da opinião do pessoal do RJ) para importação das ruas: haverão alguns poucos efeitos colaterais indesejados a serem tratados manualmente depois (como ruas duplicadas soltas ou sobrepostas), mas a quantidade é bem pequena, portanto, aceitável. 2013/12/25 Paulo Carvalho paulo.r.m.carva...@gmail.com Pessoal, Primeiro me apresento: sou o Paulo Carvalho, ex-desenvolvedor de mapas e software do Projeto Tracksource. Gostaria de manifestar meu interesse em converter o mapa da cidade do Rio de Janeiro, baseado nos mapas do IPP e CadLog (Prefeitura) para que outros usuários do OSM possam usar dados hoje não presentes no OSM da cidade, como por exemplo POIs (8000+) e numeração de casa (75% das ruas). O Fernando do RS comentou sobre um processo chamado de conflação, que permitiria agregar os dados que eu tenho com os do OSM sem destruir o que já existe. Os mapas estão no formato GTM+GTI e tenho o conversor que está bastante amadurecido, produzindo mapas OSM muito bons, completos com numeração (interpoladores) e restrições de manobra. abraço, Paulo ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Adresstagging - Karlsruher Schema
On Wed, Dec 25, 2013 at 05:44:17PM +0100, Eckhart Wörner wrote: Hallo Bernhard, Am Mittwoch, 25. Dezember 2013, 09:32:44 schrieb Bernhard Kuisle: Liebe OSMler, ich möchte mich dafür aussprechen, beim Adresstagging nicht an den Bytes zu sparen und das Karlsruher Schema trotz der Redundanz beizubehalten. Auf der anderen Seite: je mehr Daten dran stehen, desto wahrscheinlicher ist es, dass jemand Fehler macht. Je mehr daten drinstehen desto eher habe ich eine möglichkeit diese zu Validieren. Hemming Distanz und so ... (Ich hatte vor kurzem den Fall, dass jemand unabsichtlich per Copy Paste falsche Postleitzahlen in addr:postcode geschrieben hat.) Fallen ja auf den Openpostcode map sofort auf (Gibts die eigentlich wieder?) Sowohl in die eine wie in die andere Richtung. D.h. Polygon umfasst falsche Gebäude oder Gebäude haben falschen postcode. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adresstagging - Karlsruher Schema
Moin, Am 26.12.2013 00:35, schrieb Walter Nordmann: hab addr:city als Bestandteil der Postalischen Adresse wieder auf Kiel gesetzt. So sollte es richtiger sein, sorry walter ok, dann kann ich die Rute ja doch einmotten. ;-) Ist halt nicht alles so Relations-konform, wie man es gerne hätte. Generell könnte man den Datenbestand wohl reduzieren - aber mindestens für solche Sonderfälle braucht man halt die Überschreibmöglichkeit. Und die Verarbeitung würde halt nicht einfacher im Sinne von Jedermann. Wünsche noch frohe Rest-Weihnachten Georg ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Wenn gewünscht, hier ein paar Beispiele, bei denen ein Wegstück mehrfach in einer Route vorkommt, selbst wenn man jede Richtung als einzelne Route-Relation anlegt: BBH S85, früher 485 von Warburg nach Paderborn, die Variante, die über Hardehausen führt [1]. Der Bus fährt von Warburg (also im verlinkten Kartenausschnitt von der Paderborner Straße im Süden kommend), macht einen Abstecher nach Hardehausen, dreht da einmal durch die Wendeschleife, und fährt danach auf der Paderborner Straße nach Norden weiter. Wenn die Hardehausener Straße nicht mehrfach vorkommen darf: Wie löst man das dann im neuen Schema? Gleiche Linie, wenn auch nicht im Kartenbild [2] eindeutig zu sehen: De Bus kommt aus östlicher Richtung über die Warburger Straße, hält an der Haltestelle Dörenhagen, Abzweig und fährt über die Warburger Straße nach Westen weiter. Padersprinter Linie 7, und dies dürfte ein sehr gängiger Fall sein [3]: Start/Zielhaltestelle ist Friedhof auf dem Dören. Start ist aber Richtung Osten, durch die Wendeschleife und zurück - das Wegstück bis zur Wendeschleife taucht doppelt in der Lininführung auf, analoge Fälle zeigen [4] (Linie 43) sowie [5], wo alle Linien betroffen sind, die den Bahnhof nicht als Endhaltestelle anfahren (das sind ca die Hälfte, schätze ich). Mehr Beispiele such ich jetzt nicht raus, aber schwer ist das nicht die zu finden. Wer mir jetzt weiter erzählen will, dass das mit dem neuen Schema nicht erlaubt ist und dass das neue Schema besser wäre oder übernommen werden sollte, der muss mir einen guten Grund liefern, warum es besser sein sollte. Gruß Peter [1] http://www.openstreetmap.org/#map=16/51.5456/9.0059layers=T [2] http://www.openstreetmap.org/#map=18/51.67696/8.83118layers=T [3] http://www.openstreetmap.org/#map=18/51.73840/8.78768layers=T [4] http://www.openstreetmap.org/#map=17/51.73411/8.77528layers=T [5] http://www.openstreetmap.org/#map=18/51.49289/9.16251layers=T Am 25.12.2013 10:16, schrieb Wolfgang Hinsch: Am Dienstag, den 24.12.2013, 10:50 +0100 schrieb Peter Wendorff: Am 23.12.2013 07:12, schrieb Wolfgang Hinsch: Im Busbahnhof muss die Relation ggf. aufgesplittet werden in mehrere Äste. Ähnliches gilt, wenn ein Bus zum Anfahren eines Zwischenziels denselben Weg hin- und wieder zurückfährt. Dann muss die Route auf mehrere Äste verteilt werden, weil ein way nur einmal in der Relation vorhanden sein darf. Wer hat dir den den Blödsinn erzählt? Natürlich kann ein Weg mehrfach vorhanden sein, insbesondere, aber rein technisch gesehen nicht darauf beschränkt, wenn unterschiedliche Rollen (z.B. forward/backward) genutzt werden. Hab ich mehrfach so gesehen und auch mehrfach selbst so gempapped; beschwert hat sich bisher niemand. Glückwunsch! JOSM reagiert mit einer Fehlermeldung. Ob das Ganze dann heil in der DB ankommt, möchte ich nicht ausprobieren. Der Vorteil der neuen Relationen ist ja gerade, dass es eine Relation für eine Strecke gibt. Daduch kann man die Relation mit der Sort-Funktion sortieren und ggf. auf die Lücken springen, um sie zu reparieren. Wenn da jetzt wieder Verzweigungen und mehrfache Wege reinkommen, ist der Vorteil dahin. Dann hätten wir die alten Relationen lassen können. Die neuen Bus-Relationen haben lt. Wiki gar keine Role. Da die Relationen jeweils einen Weg in einer Richtung beschreiben, kann dieser Weg durch eine Kette von Anfangs-/Endpunkten bestimmt und auch berechnet werden. Auch deshalb darf es innerhalb derselben Route-Relation keine Verzweigungen geben. Wenn das so wäre, wär das neue Schema unbrauchbar, denn dass Busse, Bahnen, Straßenbahnen etc. Teilstrecken mehrfach befahren ist durchaus die Regel. Die werden als eigene Relationen innerhalb der Route-Master-Relation eingetragen. Das finde ich auch sinnvoll, denn man muss nicht mehr diese Spaghetti-Relationen verfolgen. Probleme entstehen, wenn da jetzt wieder Verzweigungen auftauchen. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adresstagging - Karlsruher Schema
Hallo Florian, Am Donnerstag, 26. Dezember 2013, 10:35:12 schrieb Florian Lohoff: Auf der anderen Seite: je mehr Daten dran stehen, desto wahrscheinlicher ist es, dass jemand Fehler macht. Je mehr daten drinstehen desto eher habe ich eine möglichkeit diese zu Validieren. Hemming Distanz und so ... (Hamming, nicht Hemming) Wir reden hier aber gerade nicht über redundante Informationen, siehe Bernhards ursprünglichen Post. Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Selbstverständlich ist es manchmal/oft notwendig highways mehrmals an eine Routerelation hin zu fügen. Manchmal sind auch stops 2x present. JOSM gibt eine Warnung, das soll kein Problem sein. Ich habe diese Warnungs abgeschaltet. Keine Ways mehr in den Routerelationen übernehmen ist auch nicht die Lösung, wie ich es verstehe, wollen wir nicht nur Routing, sondern auch eine Darstellung wo die Vehikel fahren. Wie ich die Routen jetztzutage erfasse, habe ich die richtige Sequenz von Haltestellen (aus importdata), also möchte ich lieber nicht der JOSM editor versuche die neu zu sortieren. Polyglot (der nicht so sehr gut Deutsch kennt, entschuldigung) 2013/12/26 Peter Wendorff wendo...@uni-paderborn.de Wenn gewünscht, hier ein paar Beispiele, bei denen ein Wegstück mehrfach in einer Route vorkommt, selbst wenn man jede Richtung als einzelne Route-Relation anlegt: BBH S85, früher 485 von Warburg nach Paderborn, die Variante, die über Hardehausen führt [1]. Der Bus fährt von Warburg (also im verlinkten Kartenausschnitt von der Paderborner Straße im Süden kommend), macht einen Abstecher nach Hardehausen, dreht da einmal durch die Wendeschleife, und fährt danach auf der Paderborner Straße nach Norden weiter. Wenn die Hardehausener Straße nicht mehrfach vorkommen darf: Wie löst man das dann im neuen Schema? Gleiche Linie, wenn auch nicht im Kartenbild [2] eindeutig zu sehen: De Bus kommt aus östlicher Richtung über die Warburger Straße, hält an der Haltestelle Dörenhagen, Abzweig und fährt über die Warburger Straße nach Westen weiter. Padersprinter Linie 7, und dies dürfte ein sehr gängiger Fall sein [3]: Start/Zielhaltestelle ist Friedhof auf dem Dören. Start ist aber Richtung Osten, durch die Wendeschleife und zurück - das Wegstück bis zur Wendeschleife taucht doppelt in der Lininführung auf, analoge Fälle zeigen [4] (Linie 43) sowie [5], wo alle Linien betroffen sind, die den Bahnhof nicht als Endhaltestelle anfahren (das sind ca die Hälfte, schätze ich). Mehr Beispiele such ich jetzt nicht raus, aber schwer ist das nicht die zu finden. Wer mir jetzt weiter erzählen will, dass das mit dem neuen Schema nicht erlaubt ist und dass das neue Schema besser wäre oder übernommen werden sollte, der muss mir einen guten Grund liefern, warum es besser sein sollte. Gruß Peter [1] http://www.openstreetmap.org/#map=16/51.5456/9.0059layers=T [2] http://www.openstreetmap.org/#map=18/51.67696/8.83118layers=T [3] http://www.openstreetmap.org/#map=18/51.73840/8.78768layers=T [4] http://www.openstreetmap.org/#map=17/51.73411/8.77528layers=T [5] http://www.openstreetmap.org/#map=18/51.49289/9.16251layers=T Am 25.12.2013 10:16, schrieb Wolfgang Hinsch: Am Dienstag, den 24.12.2013, 10:50 +0100 schrieb Peter Wendorff: Am 23.12.2013 07:12, schrieb Wolfgang Hinsch: Im Busbahnhof muss die Relation ggf. aufgesplittet werden in mehrere Äste. Ähnliches gilt, wenn ein Bus zum Anfahren eines Zwischenziels denselben Weg hin- und wieder zurückfährt. Dann muss die Route auf mehrere Äste verteilt werden, weil ein way nur einmal in der Relation vorhanden sein darf. Wer hat dir den den Blödsinn erzählt? Natürlich kann ein Weg mehrfach vorhanden sein, insbesondere, aber rein technisch gesehen nicht darauf beschränkt, wenn unterschiedliche Rollen (z.B. forward/backward) genutzt werden. Hab ich mehrfach so gesehen und auch mehrfach selbst so gempapped; beschwert hat sich bisher niemand. Glückwunsch! JOSM reagiert mit einer Fehlermeldung. Ob das Ganze dann heil in der DB ankommt, möchte ich nicht ausprobieren. Der Vorteil der neuen Relationen ist ja gerade, dass es eine Relation für eine Strecke gibt. Daduch kann man die Relation mit der Sort-Funktion sortieren und ggf. auf die Lücken springen, um sie zu reparieren. Wenn da jetzt wieder Verzweigungen und mehrfache Wege reinkommen, ist der Vorteil dahin. Dann hätten wir die alten Relationen lassen können. Die neuen Bus-Relationen haben lt. Wiki gar keine Role. Da die Relationen jeweils einen Weg in einer Richtung beschreiben, kann dieser Weg durch eine Kette von Anfangs-/Endpunkten bestimmt und auch berechnet werden. Auch deshalb darf es innerhalb derselben Route-Relation keine Verzweigungen geben. Wenn das so wäre, wär das neue Schema unbrauchbar, denn dass Busse, Bahnen, Straßenbahnen etc. Teilstrecken mehrfach befahren ist durchaus die Regel. Die werden als eigene Relationen innerhalb der Route-Master-Relation eingetragen. Das finde ich auch sinnvoll, denn man muss nicht mehr diese Spaghetti-Relationen verfolgen. Probleme entstehen, wenn da jetzt wieder Verzweigungen auftauchen. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Gibt es in Deutschland Haltestellen die von mehrere Operators bedient werden? In Belgien haben wir 3 Operatoren und manche Haltestellen werden auch von Niederländische Operators bedient. In diesen Fallen hatte ich erst operator=De Lijn;TEC gesetzt. Um die route_ref zu checken ist das aber zu schwierig (um das nachher automatisch zu validieren). Auch die Zonennummerierung ist unterschiedlich zwischen De Lijn, TEC und die Niederländische Operators wie Veolia, und manchmal auch die Namen. Also bin ich damit angefangen eine Node zu benutzen per Operator. So bleibt das besser getrennt. All diese Nodes gehen dann in eine stop_area Relation. Hoffentlich ist das gut so. Polyglot 2013/12/26 Jo winfi...@gmail.com Selbstverständlich ist es manchmal/oft notwendig highways mehrmals an eine Routerelation hin zu fügen. Manchmal sind auch stops 2x present. JOSM gibt eine Warnung, das soll kein Problem sein. Ich habe diese Warnungs abgeschaltet. Keine Ways mehr in den Routerelationen übernehmen ist auch nicht die Lösung, wie ich es verstehe, wollen wir nicht nur Routing, sondern auch eine Darstellung wo die Vehikel fahren. Wie ich die Routen jetztzutage erfasse, habe ich die richtige Sequenz von Haltestellen (aus importdata), also möchte ich lieber nicht der JOSM editor versuche die neu zu sortieren. Polyglot (der nicht so sehr gut Deutsch kennt, entschuldigung) 2013/12/26 Peter Wendorff wendo...@uni-paderborn.de Wenn gewünscht, hier ein paar Beispiele, bei denen ein Wegstück mehrfach in einer Route vorkommt, selbst wenn man jede Richtung als einzelne Route-Relation anlegt: BBH S85, früher 485 von Warburg nach Paderborn, die Variante, die über Hardehausen führt [1]. Der Bus fährt von Warburg (also im verlinkten Kartenausschnitt von der Paderborner Straße im Süden kommend), macht einen Abstecher nach Hardehausen, dreht da einmal durch die Wendeschleife, und fährt danach auf der Paderborner Straße nach Norden weiter. Wenn die Hardehausener Straße nicht mehrfach vorkommen darf: Wie löst man das dann im neuen Schema? Gleiche Linie, wenn auch nicht im Kartenbild [2] eindeutig zu sehen: De Bus kommt aus östlicher Richtung über die Warburger Straße, hält an der Haltestelle Dörenhagen, Abzweig und fährt über die Warburger Straße nach Westen weiter. Padersprinter Linie 7, und dies dürfte ein sehr gängiger Fall sein [3]: Start/Zielhaltestelle ist Friedhof auf dem Dören. Start ist aber Richtung Osten, durch die Wendeschleife und zurück - das Wegstück bis zur Wendeschleife taucht doppelt in der Lininführung auf, analoge Fälle zeigen [4] (Linie 43) sowie [5], wo alle Linien betroffen sind, die den Bahnhof nicht als Endhaltestelle anfahren (das sind ca die Hälfte, schätze ich). Mehr Beispiele such ich jetzt nicht raus, aber schwer ist das nicht die zu finden. Wer mir jetzt weiter erzählen will, dass das mit dem neuen Schema nicht erlaubt ist und dass das neue Schema besser wäre oder übernommen werden sollte, der muss mir einen guten Grund liefern, warum es besser sein sollte. Gruß Peter [1] http://www.openstreetmap.org/#map=16/51.5456/9.0059layers=T [2] http://www.openstreetmap.org/#map=18/51.67696/8.83118layers=T [3] http://www.openstreetmap.org/#map=18/51.73840/8.78768layers=T [4] http://www.openstreetmap.org/#map=17/51.73411/8.77528layers=T [5] http://www.openstreetmap.org/#map=18/51.49289/9.16251layers=T Am 25.12.2013 10:16, schrieb Wolfgang Hinsch: Am Dienstag, den 24.12.2013, 10:50 +0100 schrieb Peter Wendorff: Am 23.12.2013 07:12, schrieb Wolfgang Hinsch: Im Busbahnhof muss die Relation ggf. aufgesplittet werden in mehrere Äste. Ähnliches gilt, wenn ein Bus zum Anfahren eines Zwischenziels denselben Weg hin- und wieder zurückfährt. Dann muss die Route auf mehrere Äste verteilt werden, weil ein way nur einmal in der Relation vorhanden sein darf. Wer hat dir den den Blödsinn erzählt? Natürlich kann ein Weg mehrfach vorhanden sein, insbesondere, aber rein technisch gesehen nicht darauf beschränkt, wenn unterschiedliche Rollen (z.B. forward/backward) genutzt werden. Hab ich mehrfach so gesehen und auch mehrfach selbst so gempapped; beschwert hat sich bisher niemand. Glückwunsch! JOSM reagiert mit einer Fehlermeldung. Ob das Ganze dann heil in der DB ankommt, möchte ich nicht ausprobieren. Der Vorteil der neuen Relationen ist ja gerade, dass es eine Relation für eine Strecke gibt. Daduch kann man die Relation mit der Sort-Funktion sortieren und ggf. auf die Lücken springen, um sie zu reparieren. Wenn da jetzt wieder Verzweigungen und mehrfache Wege reinkommen, ist der Vorteil dahin. Dann hätten wir die alten Relationen lassen können. Die neuen Bus-Relationen haben lt. Wiki gar keine Role. Da die Relationen jeweils einen Weg in einer Richtung beschreiben, kann dieser Weg durch eine Kette von Anfangs-/Endpunkten bestimmt und auch berechnet werden. Auch deshalb darf es innerhalb derselben Route-Relation
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Hallo an alle, bin wieder zurück. Das neue Busschema halte ich für völlig unpraktikabel. Mit den Editoren iD, Potlach 2 und vermutlich auch mit Merkaartor ist das nicht mehr editierbar und mit JOSM ist der Aufwand auch erhöht, wie dieser thread zeigt. Warum definiert man solche Relationen, die fast niemand mehr bearbeiten kann? Deren dauernde Zerstörung ist doch vorhersehbar und sie behindern weiteres Editieren von Verkehrswegen, was ich als wichtiger empfinde. Relationen waren bisher immer unsortierte Sammlungen von Beziehungen. Richtungen kann man doch auch anders festlegen, z. B. mit Start und Endpunkt und meinetwegen kann man Kreuzungen als zusätzliche turn_relations innerhalb der Bus-Relationen beschreiben. Jetzt kann ich jedenfalls keine Straßenteile einfügen, weil ich die neuen Teile nicht mit akzeptablem Aufwand in die richtige Reihenfolge in der Relation einsortieren kann. Beim Teilen bereits bestehender Straßen, um z. B. eine Abbiegebeschränkung einzufügen, schiebt Potlach 2 das neue Teilstück glücklicherweise korrekt ein, wenigstens das klappt noch. Und weil in Mannheim seit Monaten die Straßennamen (Quadratenamen) nicht mehr angezeigt werden, ist OSM für mich zurzeit ziemlich unattraktiv. Das war mal besser. Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Von: Jo [mailto:winfi...@gmail.com] Gesendet: Donnerstag, 26. Dezember 2013 18:42 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??) Gibt es in Deutschland Haltestellen die von mehrere Operators bedient werden? In Belgien haben wir 3 Operatoren und manche Haltestellen werden auch von Niederländische Operators bedient. Ja. An den Haltestellen der Busbahnhöfe halten durchaus die Busse von vielen Linienbetreibern (operators). Und diese Betreiber sind auch oft am Haltestellenschild angeschrieben. In Mannheim gab es 3 Stadtbahnbetreiber, die einige Haltestellen und Gleiswege gemeinsam benutzt haben. Die Betreiber haben inzwischen allerdings fusioniert. In Heidelberg sind es noch 2 Betreiber mit gemeinsam benutzten Gleisen und Haltestellen, die aber als Verkehrsverbund auftreten. Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Am 26.12.2013 18:42, schrieb Jo: Gibt es in Deutschland Haltestellen die von mehrere Operators bedient werden? In Belgien haben wir 3 Operatoren und manche Haltestellen werden auch von Niederländische Operators bedient. Ja, die gibt es. Beispiele: Warburg Bahnhof [1] : BBH (Bahnbus Höxter; Linien 4xx und 5xx) und NVV (Nordhessischer Verkehrsverbund; Linien 1xx) Paderborn Westerntor [2] und etliche andere: Padersprinter und BBH Bei Zügen dürfte das in Deutschland sogar die Regel sein, dass neben der DB auch noch andere Betreiber die Bahnhöfe und auch einzelne Gleise nutzen. [1] http://www.openstreetmap.org/#map=18/51.49282/9.16311layers=T [2] http://www.openstreetmap.org/#map=18/51.71517/8.74521layers=T In diesen Fallen hatte ich erst operator=De Lijn;TEC gesetzt. Um die route_ref zu checken ist das aber zu schwierig (um das nachher automatisch zu validieren). Auch die Zonennummerierung ist unterschiedlich zwischen De Lijn, TEC und die Niederländische Operators wie Veolia, und manchmal auch die Namen. Vielleicht muss man hier unterscheiden zwischen dem Betreiber der Haltestelle und dem Betreiber der an der Haltestelle verkehrenden Linien. Bahnhöfe und Bahnhaltepunkte in Deutschland werden bisher meistens von einem Unternehmen der Deutschen Bahn betrieben, selbst wenn die einzigen da haltenden Linien von Fremdfirmen betrieben werden. Ist also der operator einer Haltestelle der Betreiber der Linien oder Fahrzeuge? Ich denke, zummindest nicht unbedingt. Es ist sogar ja noch ein Stück komplexer: - Betreiber der Fahrzeuge - Betreiber der Linie - Betreiber der Infrastruktur (Haltestelle, Bahnhof...) Also bin ich damit angefangen eine Node zu benutzen per Operator. So bleibt das besser getrennt. All diese Nodes gehen dann in eine stop_area Relation. Hoffentlich ist das gut so. Ich halte es zumindest nicht für ideal, wenn die Haltestelle die selbe ist. Wozu dient denn der operator-Tag an der Haltestelle? Wer wertet es zu welchem Zweck aus bzw. sollte es zu welchem Zweck auslesen können? Was kann ich daran ablesen? (auf die Gefahr, mich zu wiederholen:) Den Betreiber der fahrzeuge, der Linie oder der Infrastruktur? Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Jo schrieb: Gibt es in Deutschland Haltestellen die von mehrere Operators bedient werden? In Belgien haben wir 3 Operatoren und manche Haltestellen werden auch von Niederländische Operators bedient. Ja, je nachdem, in welchem Randgebiet du dich in Hamburg aufhältst, hast du Haltestellen, die vom HVV und VHH oder PVG (auch im VHH) angefahren werden. Das wird in anderen Bundesländern sicher ähnlich laufen. Vor allem, weil das HVV-Netz alleine ja schon eine Ausdehnung bis nach Lübeck, und Bremerhaven angenommen hat. Ich bin mir sehr sicher, dass da nicht nur der HVV die Haltestellen anfährt. … wobei bei so einem riesigen Netz außerhalb des eigentlichen Bundeslandes durchaus die Frage offen ist, ob das noch klassischer ÖPNV ist, auch wenn er zu diesem Tarif berechnet wird. Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2013-12-26T20:10:49+0100 signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Hier sind auch welche Beispiele: http://www.openstreetmap.org/node/495965408/history http://www.openstreetmap.org/node/2166716662/history http://www.openstreetmap.org/node/2166716668/history Für die Brüsseler Gesellschaft, hat diese HS Namen auf 2 Sprachen, Bus 43 bedient sie. Für STIB/MIVB gibt's keine Zone. highway http://wiki.openstreetmap.org/wiki/Key:highway?uselang=en-US bus_stophttp://wiki.openstreetmap.org/wiki/Tag:highway=bus%20stop?uselang=en-US name http://wiki.openstreetmap.org/wiki/Key:name?uselang=en-US Prince d'Orange - Prins van Oranje name:fr Prince d'Orange name:nl Prins van Oranje operatorhttp://wiki.openstreetmap.org/wiki/Key:operator?uselang=en-US STIB/MIVB route_ref 43 shelter yes Für De Lijn liegt der in Zone 20 und hat name auf Niederländisch, 136 und 137 fahren da entlang. De Lijn hat auch ref auf alle ihre Haltestellen: highway http://wiki.openstreetmap.org/wiki/Key:highway?uselang=en-US bus_stophttp://wiki.openstreetmap.org/wiki/Tag:highway=bus%20stop?uselang=en-US name http://wiki.openstreetmap.org/wiki/Key:name?uselang=en-US Prins van Oranje operatorhttp://wiki.openstreetmap.org/wiki/Key:operator?uselang=en-US De Lijn ref http://wiki.openstreetmap.org/wiki/Key:ref?uselang=en-US 301155 route_ref 136;137 zone 20 Für das TEC liegt diese HS aber schon in zone 21, Name auf Französisch und bedient von 3 Linien; 123, 124 und W (zu Waterloo) highway http://wiki.openstreetmap.org/wiki/Key:highway?uselang=en-US bus_stophttp://wiki.openstreetmap.org/wiki/Tag:highway=bus%20stop?uselang=en-US name http://wiki.openstreetmap.org/wiki/Key:name?uselang=en-US Prince d'Orange operatorhttp://wiki.openstreetmap.org/wiki/Key:operator?uselang=en-US TEC route_ref 123;124;W zone 21 Man könnte natürlich al diese Informationen auf eine Haufen schmeisen: highway http://wiki.openstreetmap.org/wiki/Key:highway?uselang=en-US bus_stophttp://wiki.openstreetmap.org/wiki/Tag:highway=bus%20stop?uselang=en-US name http://wiki.openstreetmap.org/wiki/Key:name?uselang=en-USPrince d'Orange - Prins van Oranjename:frPrince d'Orangename:nlPrins van Oranje operator http://wiki.openstreetmap.org/wiki/Key:operator?uselang=en-USSTIB/MIVB;De Lijn;TEC route_ref43;136;123;W;137;124zone20;21 Aber welche Information gehört denn zu welchen Operator??? Zone ist sogar nicht relevant für STIB/MIVB. Anderes Beispiel: http://www.openstreetmap.org/node/2527764363/history http://www.openstreetmap.org/node/1640542598/history highway http://wiki.openstreetmap.org/wiki/Key:highway?uselang=en-US bus_stophttp://wiki.openstreetmap.org/wiki/Tag:highway=bus%20stop?uselang=en-US name http://wiki.openstreetmap.org/wiki/Key:name?uselang=en-US Lommel IR Station operatorhttp://wiki.openstreetmap.org/wiki/Key:operator?uselang=en-US De Lijn ref http://wiki.openstreetmap.org/wiki/Key:ref?uselang=en-US 405820 route_ref 418;711;712;713 zone 57Für De Lijn ist das Bahnhof (Interregio) in Zone 57 Für die Niederländische Gesellschaft Hermes reicht es zu vermelden es ist das Bahnhof vorn Lommel: highway http://wiki.openstreetmap.org/wiki/Key:highway?uselang=en-US bus_stophttp://wiki.openstreetmap.org/wiki/Tag:highway=bus%20stop?uselang=en-US name http://wiki.openstreetmap.org/wiki/Key:name?uselang=en-US Lommel Station operatorhttp://wiki.openstreetmap.org/wiki/Key:operator?uselang=en-US Hermes route_ref 472 zone 6462 Die Zones in die Niederlände sind aber alle mit 4 Ziffern. Polyglot 2013/12/26 Dirk Sohler s...@0x7be.de Jo schrieb: Gibt es in Deutschland Haltestellen die von mehrere Operators bedient werden? In Belgien haben wir 3 Operatoren und manche Haltestellen werden auch von Niederländische Operators bedient. Ja, je nachdem, in welchem Randgebiet du dich in Hamburg aufhältst, hast du Haltestellen, die vom HVV und VHH oder PVG (auch im VHH) angefahren werden. Das wird in anderen Bundesländern sicher ähnlich laufen. Vor allem, weil das HVV-Netz alleine ja schon eine Ausdehnung bis nach Lübeck, und Bremerhaven angenommen hat. Ich bin mir sehr sicher, dass da nicht nur der HVV die Haltestellen anfährt. … wobei bei so einem riesigen Netz außerhalb des eigentlichen Bundeslandes durchaus die Frage offen ist, ob das noch klassischer ÖPNV ist, auch wenn er zu diesem Tarif berechnet wird. Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2013-12-26T20:10:49+0100 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wochennotiz Nr. 179 17.12.-23.12.2013
Hallo, die Wochennotiz Nr. 179 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/blog/2013/12/wochennotiz-nr-179/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Komplizierte Konstrukte - WAS: Zeitreise ins 4. Jahrhundert oder was?
Von: Tirkon [mailto:tirko...@yahoo.de] Gesendet: Samstag, 21. Dezember 2013 14:55 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Komplizierte Konstrukte - WAS: Zeitreise ins 4. Jahrhundert oder was? Bernhard Weiskopf bweisk...@gmx.de wrote: In meiner Umgebung sind ein paar breite Hauptstraßen an Kreuzungen aufgeteilt in zwei Richtungsfahrbahnen und in der Mitte sind Inseln für Fußgänger und Radfahrer. Diese Aufteilung und damit das genauere Eintragen von Fuß- und Radwegen würde ich gerne auch in OSM abbilden, wo die Straßen zurzeit als jeweils eine durchgehende Linie eingetragen sind. Könntest Du das Beispiel in osm.org verlinken? Hallo Tirkon, die Kreuzungen habe ich mir nicht alle gemerkt, die werde ich sowieso nicht anfassen. Die letzte, die ich mir angeschaut habe, ist die Kreuzung Herzogenriedstraße/Zum Herrenried in Mannheim: http://www.openstreetmap.org/?mlat=49.51014mlon=8.48378#map=19/49.51014/8. 48378 oder https://maps.google.de/?ll=49.51014,8.48378spn=0.000906,0.002497t=mz=19 Da fehlen auch noch Abbiegerelationen, die will ich aber erst eintragen, wenn die Fahrbahnen der Herzogenriedstraße um die Inseln getrennt sind. An der breitesten Stelle ist die Herzogenriedstraße mit dem einseitigen Rad- und Gehweg 25 m breit. Da über diese Straßen aber Bus-Relationen führen und nach deren neuen Schema die Straßensegmente in der Relationsliste in der richtigen Reihenfolge eingetragen werden müssen und das Ganze auch noch für jede Fahrtrichtung einzeln, lasse ich das Editieren sein. Das ist mir inzwischen zu aufwändig zu pflegen. Zu diesem Thema habe ich mit einen ausführlichen Beitrag einen Nachbar-Thread gestartet: Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??) Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Am 26/dic/2013 um 18:42 schrieb Jo winfi...@gmail.com: Gibt es in Deutschland Haltestellen die von mehrere Operators bedient werden? In Belgien haben wir 3 Operatoren und manche Haltestellen werden auch von Niederländische Operators bedient. Ja, dass Linien die von unterschiedlichen Operators betrieben werden, dieselbe Haltestelle nutzen kommt sicher oft vor, aber die Linien haben normalerweise nur einen Operator, und der ist auch nicht unbedingt derselbe wie der der Haltestelle. Im Zweifel (d.h. wenn man nicht genau weiß, wer die Haltestelle betreibt) besser gar keinen operator Tag an die Haltestelle taggen sondern nur an die Linie... Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Ich benutze operator auf die Haltestellen um die mit Overpass runterladen zu können. Für mich heisst Operator auf die Haltestelle das diese Haltestelle von diesen Operator bedient wird. Diese Haltestelle sieht aus wie alle andere von De Lijn: http://www.openstreetmap.org/node/1183224590/history Wir aber nur von TEC-büsse bedient. Das gleiche gilt für den hier: http://www.openstreetmap.org/node/1183224596/history Die Zone ist 17. Wenn da ein bus von De Lijn entlang fahren würde, dann würde das Zone 18 sein (sowie alle HS in der Umgebung). Vielleicht kommt solches in Deutschland nicht vor, dass Namen, Zones, ref und route_ref unterschiedlich sind. Jedenfalls ist die über verschiedene Nodes trennen, und dann mit stop_area wieder zusammenfassen, eine Lösung die für uns funktioniert. Polyglot 2013/12/26 Martin Koppenhoefer dieterdre...@gmail.com Am 26/dic/2013 um 18:42 schrieb Jo winfi...@gmail.com: Gibt es in Deutschland Haltestellen die von mehrere Operators bedient werden? In Belgien haben wir 3 Operatoren und manche Haltestellen werden auch von Niederländische Operators bedient. Ja, dass Linien die von unterschiedlichen Operators betrieben werden, dieselbe Haltestelle nutzen kommt sicher oft vor, aber die Linien haben normalerweise nur einen Operator, und der ist auch nicht unbedingt derselbe wie der der Haltestelle. Im Zweifel (d.h. wenn man nicht genau weiß, wer die Haltestelle betreibt) besser gar keinen operator Tag an die Haltestelle taggen sondern nur an die Linie... Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Martin Koppenhoefer schrieb: Ja, dass Linien die von unterschiedlichen Operators betrieben werden, dieselbe Haltestelle nutzen kommt sicher oft vor, aber die Linien haben normalerweise nur einen Operator, Ich glaube, mich erinnern zu können, dass hier in Hamburg sowohl HVV-Busse als auch solche vom VHH für die selbe Linie eingesetzt werden, wobei ich jetzt natürlich nicht weiß, ob das einfach „Schützenhilfe“ durch Busbereitstellung ist, oder tatsächliche Arbeitsteilung unter den Verbänden. Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2013-12-27T05:45:30+0100 signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] adesione a beni culturali aperti
Il 24/12/2013 15:02, Simone Cortesi ha scritto: 2013/12/24 Francesca Valentina coretodes...@gmail.com: @Aury88 infatti hai detto bene. Aderite, aderite :) ne gioviamo tutti eccoci! http://www.beniculturaliaperti.it/adesioni/ Aderiamo :-) -- RISPETTA L'AMBIENTE: SE NON TI E' NECESSARIO, NON STAMPARE QUESTA E-MAIL. Le informazioni contenute in questa comunicazione sono riservate e destinate esclusivamente alla/e persona/e o all'ente/i a cui sono stati indirizzati. Se questa comunicazione Vi e' pervenuta per errore, siete pregati di informare il mittente rispondendo a questa mail. I dati riportati nel presente documento sono trattati nel rispetto del D.Lgs. 196/2003 (Codice della Privacy) sulla tutela dei dati personali. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Track in JOSM italiano
Il 24/12/2013 21:49, rattorosso ha scritto: Il giorno mar, 24/12/2013 alle 21.24 +0100, solitone ha scritto: Volker Schmidt ha scritto: Il mio punto è che la traduzione della categoria track è sbagliato. Per me dovrebbe essere qualcosa come strada carrabile. Mettere sterrato nel titolo è sbagliato. +1 Primo, sterrato non rende l'idea: come detto più volte, molte strade sterrate non sono track (es. strade residential o unclassified nelle zone di campagna). Secondo, non tutte le track sono sterrate. Secondo me la giusta traduzione dovrebbe essere carrareccia. Oppure secondo me sarebbe meglio togliere proprio la definizione strada e chiamarlo percorso carrabile o qualcosa di simile http://it.wikipedia.org/wiki/Classificazioni_delle_strade_in_Italia ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Track in JOSM italiano
Il 25/12/2013 12:02, Volker Schmidt ha scritto: Voi di madrelingua italiana, mettetevi d'accordo sul termine. :-) In futuro la madrelingua sarà solo un lontano ricordo:-) Poi: chi sa come si cambia il preset in JOSM? Buone Feste Volker 2013/12/24 rattorosso floydbar...@alice.it mailto:floydbar...@alice.it Il giorno mar, 24/12/2013 alle 21.24 +0100, solitone ha scritto: Volker Schmidt ha scritto: Il mio punto è che la traduzione della categoria track è sbagliato. Per me dovrebbe essere qualcosa come strada carrabile. Mettere sterrato nel titolo è sbagliato. +1 Primo, sterrato non rende l'idea: come detto più volte, molte strade sterrate non sono track (es. strade residential o unclassified nelle zone di campagna). Secondo, non tutte le track sono sterrate. Secondo me la giusta traduzione dovrebbe essere carrareccia. Oppure secondo me sarebbe meglio togliere proprio la definizione strada e chiamarlo percorso carrabile o qualcosa di simile Lorenzo ___ Talk-it mailing list Talk-it@openstreetmap.org mailto:Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it -- Volker SCHMIDT Via del Cristo 28 35127 Padova Italy mailto:vosc...@gmail.com mailto:vosc...@gmail.com personal mobile: +39-340-1427105 skype: volker.schmidt ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it -- RISPETTA L'AMBIENTE: SE NON TI E' NECESSARIO, NON STAMPARE QUESTA E-MAIL. Le informazioni contenute in questa comunicazione sono riservate e destinate esclusivamente alla/e persona/e o all'ente/i a cui sono stati indirizzati. Se questa comunicazione Vi e' pervenuta per errore, siete pregati di informare il mittente rispondendo a questa mail. I dati riportati nel presente documento sono trattati nel rispetto del D.Lgs. 196/2003 (Codice della Privacy) sulla tutela dei dati personali. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: pista ciclabile a due corsie con superficie diverse
La Foto che Martin ha indicato, sembra essere presa sulla stessa pista che dico io (nella parte più vecchia vicino a Blumau). Nella foto la parte sterrata sembra più stretta e quasi abbandonata. I pezzi che io ricordo (l'ho fatto da Bolzano al Brennero nel 2010 poche settimane prima dell'inaugurazione ufficiale del ultimo pezzo che porta al Brennero) la parte sterrata era larga come la parte asfaltata. Il problema con la proposta delle due via di Beppe è, oltre al lavoro della mappatura, il fatto che non c'è separazione fisica fra le due corsie, sono proprio attaccate e si può cambiare da una all'altra al momento. Ho guardato un po' le foto di Google: https://encrypted.google.com/search?q=eisacktal+radweglr=safe=imageshl=ensource=lnmstbm=ischsa=Xei=Xf67UunCO4j-ygOhnYK4Agved=0CAcQ_AUoAQbiw=1048bih=709 Si vede chiaramente su tante foto la corsia sterrata, più o meno coperta da herba. 2013/12/26 Giuseppe Amici giuseppeam...@virgilio.it Utilizzando due way separate e con attributi diversi? Beppe *Da:* Volker Schmidt [mailto:vosc...@gmail.com] *Inviato:* mercoledì 25 dicembre 2013 16:37 *A:* openstreetmap list - italiano *Oggetto:* [Talk-it] pista ciclabile a due corsie con superficie diverse La ciclovia Eisacktal Radweg - Pista Ciclabile della Valle Isarco (relation 411917) è fatta su tratti lunghi da due corsie attaccate: una asfaltata (per touringbike) e una in giaia (per MTB e forse anche per cavalli). Esempio: http://www.openstreetmap.org/way/169569052 Al momento è taggata solo con surface=asphalt. Se sono in giro con la MTB (o cavallo) mi interessa sapere che c'è anche una corsia in in ghiaia, suppongo. Come si fa? Volker ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it -- Volker SCHMIDT Via del Cristo 28 35127 Padova Italy mailto:vosc...@gmail.com personal mobile: +39-340-1427105 skype: volker.schmidt ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] pista ciclabile a due corsie con superficie diverse
2013/12/25 Volker Schmidt vosc...@gmail.com La ciclovia Eisacktal Radweg - Pista Ciclabile della Valle Isarco (relation 411917) è fatta su tratti lunghi da due corsie attaccate: una asfaltata (per touringbike) e una in giaia (per MTB e forse anche per cavalli). Esempio: http://www.openstreetmap.org/way/169569052 Come si fa? Magari si possono usare :left e :right. Quindi surface:left=asphalt e surface:right=gravel? Ciao, Andrea. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] pista ciclabile a due corsie con superficie diverse
Il giorno 26/dic/2013 11:14, Andrea Musuruane musur...@gmail.com ha scritto: 2013/12/25 Volker Schmidt vosc...@gmail.com La ciclovia Eisacktal Radweg - Pista Ciclabile della Valle Isarco (relation 411917) è fatta su tratti lunghi da due corsie attaccate: una asfaltata (per touringbike) e una in giaia (per MTB e forse anche per cavalli). Esempio: http://www.openstreetmap.org/way/169569052 Come si fa? Magari si possono usare :left e :right. Quindi surface:left=asphalt e surface:right=gravel? Anch'io userei questa soluzione Ciao, Andrea. Ciao Luca ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [OT] Fwd: Shoothill FloodAlerts. You have: 1 new notification
quotando: «Ma il vero valore aggiunto sono i dati dell'Agenzia Ambientale UK, da sensori ed elaborati ogni 15 minuti per produrre aree di possibile esondazione.» Lodevole iniziativa, con molti dubbi di applicabilità in Italia. Oltre ai problemi gestionali esiste anche quello di tipo psicologico. Gravi problemi gestionali per l'ufficio idrografico di Roma, a quanto pare. Il sito con i valori dell'idrometro non si aggiorna dal 9 Dicembre. Ho scritto un email e mi hanno risposto che devono risolvere e nel frattempo di chiamare un numero verde... Certo che un sistema di alert basato su questi servizi scadentialtro che UK... ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [OT] Fwd: Shoothill FloodAlerts. You have: 1 new notification
http://www.idrografico.roma.it/default.aspx ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] pista ciclabile a due corsie con superficie diverse
Am 26/dic/2013 um 12:08 schrieb Luca Delucchi lucadel...@gmail.com: Magari si possono usare :left e :right. Quindi surface:left=asphalt e surface:right=gravel? Anch'io userei questa soluzione +1 in realtà la parte sterrata farei probabilmente perdere, tanto puoi spesso andare su un sterrato accanto una pista asfaltata, ma ne anche in MTB mi verrebbe in mente di farlo ;-) ciao, Martin___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-se] hastighetsbegränsningar
Finemang, det verkar som om man kan lägga det som ett custom-lager i iD med
följande URL:
http://t1.beta.itoworld.com/124/516d29fbe530601e40e536d6a388e442/{z}/{x}/{y}.png?fullscreen=true
Eftersom deras data kommer från OSM från början och i det här fallet bara
används för att se var det saknas OSM-data så kan jag inte se att det
skulle finnas några upphovsproblem att använda den som underlag när man
ritar... Man måste ju ändå tillföra den faktiska informationen från någon
annanstans (tex lokal kännedom). Någon av er här på listan som kan se något
problem jag missat?
/Jonas
2013/12/25 Joel Grafström j...@torsson.se
Finns ett kartlager för hastighet på ITO maps.
http://www.itoworld.com/map/124?lon=14.20342lat=57.77957zoom=11fullscreen=true
//Joel
Jonas Hogstrom skrev 2013-12-25 00:24:
Hej och god jul på er
Efter att ha börjat köra med OsmAnd http://osmand.net/har jag insett
att även om vägnätet till stora delar är väl karterat så saknas det
hastighetsbegränsningsinformation på väldigt stor del av vägarna...
Är det nån av er som har erfarenhet av kartrendering som vet hur svårt
det skulle vara att göra ett kartlager som visade bara vägar, och renderade
färgen baserat på vilken hastghetsbegränsning som är karterad (och nån
ordentligt avvikande färg för vägar helt utan hastighetsbegränsningsinfo)?
Med en sådan tileserver som bakgrund borde det bli betydligt enklare att
komplettera vägnätet med vettiga hastighetsgränser.
På trafikverket finns det översiktskartor med dom
hastighetsbegränsningar (på större vägar) som beslutades 2009
(uppdaterad/granskad 2010):
http://www.trafikverket.se/Privat/Resan-och-trafiken/Hastighetsgranser-pa-vag/Nya-hastighetsgranser/Kartor---nya-hastighetsgranser/
Där finns också detaljkartor för varje län.
Har inte hittat vad som gäller rättighetsmässigt för dessa kartor än. Är
det någon från OSM som varit i kontakt med trafikverket i något annat
ärende? Underlaget till kartorna är ju troligen lagbeslut, men trafikverket
kan ju ha rättigheter till sina kartor ändå antar jag.
/Jonas
___
Talk-se mailing
listTalk-se@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-se
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se
Re: [Talk-at] kittsee - semiautomated import of buildings from basemap.at
hello all, i've been playing a bit with potrace - a bitmap to vector tool trying to automate building shapes extraction from basemap.at ( http://wiki.openstreetmap.org/wiki/AT/basemap). as this could be considered mass import, i would like to have austrian mapper community checked/approved this first. i am planning to do a few fixes here and there but generally i consider https://db.tt/eUm1BLmg to be ready for upload to osm. please let me know if it meets your quality criteria for imports or just share your thoughts/ideas. vielen dank, jose (greetings from slovakia) ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] kittsee - semiautomated import of buildings from basemap.at
On 26/12/13 11:01, Jozef Riha wrote: hello all, Hello Jozef, i've been playing a bit with potrace Impressive result - can you provide a how-to for recreating (and maybe improving) the steps you've accomplished? - a bitmap to vector tool trying to automate building shapes extraction from basemap.at http://basemap.at (http://wiki.openstreetmap.org/wiki/AT/basemap). as this could be considered mass import, i would like to have austrian mapper community checked/approved this first. i am planning to do a few fixes here and there but generally i consider https://db.tt/eUm1BLmg to be ready for upload to osm. please let me know if it meets your quality criteria for imports or just share your thoughts/ideas. I've reviewed it, but there are some flaws which (in my opinion) are blocking the import: * adjacent buildings do not share nodes * no multipolygons at buildings with holes - those would have to be created manually * The buildings are not orthogonalized (q in JOSM) * nodes at very obtuse angles (e.g. 88°) should be removed. vielen dank, Ein großes Danke for your efforts! jose (greetings from slovakia) Greetings, Michael -- Michael Maier, Student of Telematics @ Graz University of Technology OpenStreetMap Graz http://osm.org/go/0Iz@paV http://wiki.osm.org/Graz http://wiki.osm.org/Graz/Stammtisch signature.asc Description: OpenPGP digital signature ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] kittsee - semiautomated import of buildings from basemap.at
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, before this is imported it would at least need proper documentation on the Wiki import catalogue. In addition to the points mentioned by Michael - * adjacent buildings do not share nodes * no multipolygons at buildings with holes - those would have to be created manually * The buildings are not orthogonalized (q in JOSM) * nodes at very obtuse angles (e.g. 88°) should be removed. I would like to add * source tag on every building (source tag on changeset would be enough) * existing buildings are not reflected - they would have to be removed from the import data. * very small buildings seem to be badly traced (triangular shapes etc) - - perhaps just drop everything below 10 square metres or so. There seem to be a number of mismatches between the data and Bing imagery - but I guess that's because basemap.at is newer? Examples: http://www.remote.org/frederik/tmp/kittsee.png Bye Frederik - -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSvFSXAAoJEOx/uhGAJu9H1EcH/inTfdlr5O2KTLkIiiueRrfI hZvIjzgCxNvSj2SBgq2gWO3HayE6+X2yzUWOvQH3LCo5h1CT+qtvl1oL3cczlxhJ dn1a0dLAtZ3lgog+GshkRSm2Ih6lvaeWE5VUByZuvlgy4YYC/USXx912+Q5UASdr LkbMRhcdM0QwBY1vgBXOatYnzBONRzkylO1ngFV91Rx6Ggh4hdsAP3bjyf6eyQmC v4SNecG7uNPgC4cmpkM16R9EoKbCuqxhzfmY0QcaqgIFEujiTHbHLU0NqkEAbjys LmBhIiDZdL2RdL0Kp0zQ8uUnN3CLOVPiy9sseYWpXzZpV8Z4a3u9OzfmcCfXOSs= =PT+P -END PGP SIGNATURE- ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] kittsee - semiautomated import of buildings from basemap.at
On 26.12.13 17:09, Frederik Ramm wrote: There seem to be a number of mismatches between the data and Bing imagery - but I guess that's because basemap.at is newer? Examples: http://www.remote.org/frederik/tmp/kittsee.png (ich antworte auf Deutsch) Es ist sehr zu empfehlen, mit geoimage.at zu vergleichen, weil das (meist) das Aktuellste ist. Dort sieht man z.B., dass die nördlichen zwei Fragezeichen offensichtlich abgerissen sind. Das Problem ist, es kann alles veraltet sein, auch basemap.at (scheint mir beim südlichsten Fragezeichen = Gst. Kittsee 203/2 so zu sein). Man sieht aber auch Fehler, z.B. das Haus ganz im NO (2421 Landstraße 13a, Gst. Kittsee 186/2) hat in Wahrheit eine rechteckige Grundfälche, der Algorithmus hat da eine Nische erfunden, die es nicht gibt. Und wie schon gesagt, bitte bestehende Gebäude beachten. Zusätzlich sollte man auch Adressen möglichst vollständig erfassen, was in aller Regel höchstens halbautomatisch möglich ist (Jedenfalls ist die Info, auf welche Straße sich eine Hausnummer bezieht, in basemap.at nicht vorhanden, das muss man wissen oder recherchieren!). /al ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] kittsee - semiautomated import of buildings from basemap.at
Thank you all for sharing your views. I chose not to go further with the import - instead I will describe the procedure I used - maybe someone could come up with improvements that would make the result look better/actually usable. - create a basemap.at xml config for mobac (http://mobac.sourceforge.net/), select and export to png file (zoom: 19) - open png file in gimp, select - by color, click on one building, copypaste to new file, threshold, index - 2 colours (potrace requires bi-color image), save buildings into pnm file - potrace -t 100 -k 0.3 -o kittsee.svg -s kittsee.pnm - import to josm (importvec plugin, 10 000 units = 1995 m) - select all ways (^f - type:way - simplify using simplifyarea plugin, using too aggressive values could result in triangular buildings, OTOH too forgiving ones could leave you with too many nodes and/or speckles caused by nearby housenumbers or jpeg artefacts - turn on basemap.at tms background and align, tidy up, add tags All the best, jose On Thu, Dec 26, 2013 at 5:09 PM, Frederik Ramm frede...@remote.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, before this is imported it would at least need proper documentation on the Wiki import catalogue. In addition to the points mentioned by Michael - * adjacent buildings do not share nodes * no multipolygons at buildings with holes - those would have to be created manually * The buildings are not orthogonalized (q in JOSM) * nodes at very obtuse angles (e.g. 88°) should be removed. I would like to add * source tag on every building (source tag on changeset would be enough) * existing buildings are not reflected - they would have to be removed from the import data. * very small buildings seem to be badly traced (triangular shapes etc) - - perhaps just drop everything below 10 square metres or so. There seem to be a number of mismatches between the data and Bing imagery - but I guess that's because basemap.at is newer? Examples: http://www.remote.org/frederik/tmp/kittsee.png Bye Frederik - -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSvFSXAAoJEOx/uhGAJu9H1EcH/inTfdlr5O2KTLkIiiueRrfI hZvIjzgCxNvSj2SBgq2gWO3HayE6+X2yzUWOvQH3LCo5h1CT+qtvl1oL3cczlxhJ dn1a0dLAtZ3lgog+GshkRSm2Ih6lvaeWE5VUByZuvlgy4YYC/USXx912+Q5UASdr LkbMRhcdM0QwBY1vgBXOatYnzBONRzkylO1ngFV91Rx6Ggh4hdsAP3bjyf6eyQmC v4SNecG7uNPgC4cmpkM16R9EoKbCuqxhzfmY0QcaqgIFEujiTHbHLU0NqkEAbjys LmBhIiDZdL2RdL0Kp0zQ8uUnN3CLOVPiy9sseYWpXzZpV8Z4a3u9OzfmcCfXOSs= =PT+P -END PGP SIGNATURE- ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] kittsee - semiautomated import of buildings from basemap.at
Jozef Riha schrieb: Thank you all for sharing your views. I chose not to go further with the import - instead I will describe the procedure I used - maybe someone could come up with improvements that would make the result look better/actually usable. Thanks both for the work in figuring this out (as well as trying it and now describing it here) and for not going forward with it in that straight way. For the latter, we unfortunately know that there are many inaccuracies in the basemap.at data so it needs to be looked over by people with local knowledge when taking it as a source for any OSM work. That doesn't mean it's useless, on the contrary it can be very helpful, but it always has to be taken with a grain of salt and verified by other material and ideally people who know the scenery on the ground. Thanks and Cheers, Robert Kaiser ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] JOYEUX LE(ar)NO(sm)
2013/12/25 Severin MENARD severin.men...@gmail.com: Le Père Noël a apporté une traduction en français des guides intermédiaires et avancés LearnOSM pour tous les contributeurs francophones du monde (sages ou pas) : rendez-vous sur http://learnosm.org/fr/ puis sur Les Autres Guides. Il faudra attendre encore un peu pour Vous Organisez Un Atelier ?, mais a priori pas jusqu'au Noël prochain. Dommage que personne ne pense à corriger les erreurs et approximations du guide original avant de le traduire. Mais l'intention est louable. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOYEUX LE(ar)NO(sm)
Le 26/12/2013 14:27, Pieren a écrit : 2013/12/25 Severin MENARD severin.men...@gmail.com: Le Père Noël a apporté une traduction en français des guides intermédiaires et avancés LearnOSM pour tous les contributeurs francophones du monde (sages ou pas) : rendez-vous sur http://learnosm.org/fr/ puis sur Les Autres Guides. Il faudra attendre encore un peu pour Vous Organisez Un Atelier ?, mais a priori pas jusqu'au Noël prochain. Dommage que personne ne pense à corriger les erreurs et approximations du guide original avant de le traduire. Mais l'intention est louable. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr Bonjour, J'ai besoin d'une aide. En tant qu'administrateur du site http://belfort-montbeliard.mondio16.com/mini_sites/notredame-belchamp/, je tente de télécharger une carte OSM des communes de Mandeure et Valentigney (contour administratif de ces deux communes) que je nommerais Paroisse Notre-Dame de Belchamp afin d'y indiquer les lieux et l'incorporer dans ce site à la place de l'image google. J'ai installé JOSM (dernière version .jar tested). Une sélection rectangulaire de ces deux communes me dit que ma requête est trop grosse. Je ne trouve pas de solution. Une idée? Cordialement, Patrik Ulrich ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOYEUX LE(ar)NO(sm)
Le 26/12/2013 15:36, Patrik.ulrich a écrit : Le 26/12/2013 14:27, Pieren a écrit : 2013/12/25 Severin MENARD severin.men...@gmail.com: Le Père Noël a apporté une traduction en français des guides intermédiaires et avancés LearnOSM pour tous les contributeurs francophones du monde (sages ou pas) : rendez-vous sur http://learnosm.org/fr/ puis sur Les Autres Guides. Il faudra attendre encore un peu pour Vous Organisez Un Atelier ?, mais a priori pas jusqu'au Noël prochain. Dommage que personne ne pense à corriger les erreurs et approximations du guide original avant de le traduire. Mais l'intention est louable. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr Bonjour, J'ai besoin d'une aide. En tant qu'administrateur du site http://belfort-montbeliard.mondio16.com/mini_sites/notredame-belchamp/, je tente de télécharger une carte OSM des communes de Mandeure et Valentigney (contour administratif de ces deux communes) que je nommerais Paroisse Notre-Dame de Belchamp afin d'y indiquer les lieux et l'incorporer dans ce site à la place de l'image google. je n'ai pas trouve l'image google dont tu parle, je suis pas sur de comprendre ton besoin J'ai installé JOSM (dernière version .jar tested). Une sélection rectangulaire de ces deux communes me dit que ma requête est trop grosse. Je ne trouve pas de solution. Une idée? essaye d'utiliser leaflets ou encore openlayers, ca permet de faire des cates du genre celles qui sont la : http://www.ffdn.org/wiki/doku.php?id=essaimage http://www.enercoop.fr/index.asp?id=669 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOYEUX LE(ar)NO(sm)
Le 26/12/2013 16:17, hamster a écrit : Le 26/12/2013 15:36, Patrik.ulrich a écrit : Le 26/12/2013 14:27, Pieren a écrit : 2013/12/25 Severin MENARD severin.men...@gmail.com: Le Père Noël a apporté une traduction en français des guides intermédiaires et avancés LearnOSM pour tous les contributeurs francophones du monde (sages ou pas) : rendez-vous sur http://learnosm.org/fr/ puis sur Les Autres Guides. Il faudra attendre encore un peu pour Vous Organisez Un Atelier ?, mais a priori pas jusqu'au Noël prochain. Dommage que personne ne pense à corriger les erreurs et approximations du guide original avant de le traduire. Mais l'intention est louable. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr Bonjour, J'ai besoin d'une aide. En tant qu'administrateur du site http://belfort-montbeliard.mondio16.com/mini_sites/notredame-belchamp/, je tente de télécharger une carte OSM des communes de Mandeure et Valentigney (contour administratif de ces deux communes) que je nommerais Paroisse Notre-Dame de Belchamp afin d'y indiquer les lieux et l'incorporer dans ce site à la place de l'image google. je n'ai pas trouve l'image google dont tu parle, je suis pas sur de comprendre ton besoin Onglet 'Les lieux sur http://belfort-montbeliard.mondio16.com/mini_sites/notredame-belchamp/ J'ai installé JOSM (dernière version .jar tested). Une sélection rectangulaire de ces deux communes me dit que ma requête est trop grosse. Je ne trouve pas de solution. Une idée? essaye d'utiliser leaflets ou encore openlayers, ca permet de faire des cates du genre celles qui sont la : http://www.ffdn.org/wiki/doku.php?id=essaimage http://www.enercoop.fr/index.asp?id=669 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr Merci ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOYEUX LE(ar)NO(sm)
*Bonjour Patrik et à toutes et tous.* *@Patrik : ce que tu cherche à obtenir c'est affiché les ' Données ' d'OpenStreetMap sur un ' Rendu ' de carte dans ton site internet. * *Donc, tu a plusieurs solutions pour arriver au résultat escompté.* *- Soit tu veut afficher ce que l'ont peut voir sur le site www.openstreetmap.org http://www.openstreetmap.org , pour ça c'est simple, * *tu te positionne sur la zone qui t'intéresse, puis, tu a une icone situé sur la droite de la page celle qui se trouve juste au dessous de l'icone ' i ' * *tu clique dessus et s’ouvre un volet avec les choix pour récupéré le code à insérer dans ton site web.* *- J'ai visiter ton site web que tu donne en lien, c'est fait avec ' WordPress ', pour ce CMS il y a un Plugin pour afficher les ' Données ' dans un ' rendu ' le tout à mettre où tu veut dans le site internet. * *Voir ce lien : http://wordpress.org/plugins/osm/ http://wordpress.org/plugins/osm/ c'est peut-être plus simple pour toi, et pour le résultat que tu cherche à obtenir. * *- Autre service qui peut peut-être te convenir, c'est ' UMap ' : http://umap.openstreetmap.fr/fr/ http://umap.openstreetmap.fr/fr/ ce site permet d'obtenir une carte personnalisé à partir des ' Données ' d'OpenStreetMap et d'autres sources personnelles.* *Nota : OpenStreetMap n'est pas Google Maps, ce n'est pas le même fonctionnement et pas la même philosophie. * *Nota 2 : JOSM sers à ' Éditer ' les ' Données ' qui se trouve dans la Base De Données et dans ajoutés d'autres.* *Nota 3 : Il est préférable de créer un nouveau message avec un titre de message simple mais clair, que de répondre à un sujet existant.* * Voilà.* *Amicalement.Olivier Griffet http://griffet.net/ | Contributeur OpenStreetMap = http://www.openstreetmap.org/user/olivier_griffet_83660_carnoules http://www.openstreetmap.org/user/olivier_griffet_83660_carnoules || Habitant de 83660 http://www.openstreetmap.org/export/embed.html?bbox=6.17628,43.29493,6.19694,43.30505layer=mapnikmarker=43.29837,6.18737 - Carnoules http://carnoules.fr/ - Var | Adhérent de GULLIVAR et ToulonuX | Utilisateur de GNU/LINUX de * *(X)Ubuntu 12.04 [ XFCE ] ; Lives USB ASRI.EDU.300 ; Etc...Site web de GULLIVAR : http://gullivar.org/ http://gullivar.org/ Site web de ToulonuX : http://toulonux.tuxfamily.org/ http://toulonux.tuxfamily.org/* - Le 26 décembre 2013 15:36, Patrik.ulrich a écrit : Bonjour, J'ai besoin d'une aide. En tant qu'administrateur du site http://belfort-montbeliard.mondio16.com/mini_sites/notredame-belchamp/, je tente de télécharger une carte OSM des communes de Mandeure et Valentigney (contour administratif de ces deux communes) que je nommerais Paroisse Notre-Dame de Belchamp afin d'y indiquer les lieux et l'incorporer dans ce site à la place de l'image google. J'ai installé JOSM (dernière version .jar tested). Une sélection rectangulaire de ces deux communes me dit que ma requête est trop grosse. Je ne trouve pas de solution. Une idée? Cordialement, Patrik Ulrich ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux...
Et ben, c'est demandé tellement gentiment que je vais me presser d'améliorer les choses pour vous seoir... 2013/12/23 PierreV belett...@hotmail.fr: c'est juste dommage qu'il faille s'inscrire même pour tester, du coup j'ai même pas testé... je ne voit pas comment on peut créer des applis' de ce genre et se permettre de balancer le lien sur une liste d'un projet libre... -- View this message in context: http://gis.19327.n5.nabble.com/codes-postaux-tp5790531p5790699.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comcom Maker
On a du nouveau de ce coté ? Florian. Le Dimanche 24 novembre 2013 16h56, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Le 24/11/2013 16:49, Vincent de Château-Thierry a écrit : Bonjour, Le 24/11/2013 16:08, Christian Quest a écrit : Il se trouvait sur osm7 avant que celui-ci ne tombe en panne et soit totalement ré-installé. Il va être remis en route, surtout qu'avec 100% des communes on va pouvoir viser le 100% d'EPCI et autres découpages du même genre. Le 24 novembre 2013 16:00, Otourly Wiki otou...@yahoo.fr mailto:otou...@yahoo.fr a écrit : Bonjour, il semblerait que cet outil ne soit plus disponible. C'est gênant, car avec la réforme des collectivités territoriales en janvier prochain il va y avoir du pain sur la planche... Florian. En complément sur le thème des EPCI, je (re)signale cette source : http://www.data.gouv.fr/DataSet/572273 Il donne la liste, par EPCI, des communes membres, au 01/01/2013. Sa mise à jour sera intéressante l'année prochaine bien sûr, mais la réforme a déjà eu des effets cette année. Je m'occupe de remettre comcom maker en route. C'est en cours. Pour ce qui est des EPCI, et comme je l'avais fait pour les cantons, on peut utiliser comcommaker en ligne de commande. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] way des limites administratives
Petite question suite a une carte vu sur ito map : Faut il que les tag admin level se trouve sur les way des limites communales obligatoirement? Je suis tombé sur la carte ito map des limites admin http://www.itoworld.com/map/2?lon=4.76595lat=47.40815zoom=9fullscreen=true On voit qu'a certains endroits il n'y a pas de admin level (en gris sur la carte) il y a aussi des endroit ou les way des relations ne possède aucun tag : http://www.itoworld.com/map/2?lon=1.92736lat=48.24036zoom=10fullscreen=true ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] way des limites administratives
Le 26/12/2013 19:08, Jérôme Amagat a écrit : Petite question suite a une carte vu sur ito map : Faut il que les tag admin level se trouve sur les way des limites communales obligatoirement? Je suis tombé sur la carte ito map des limites admin http://www.itoworld.com/map/2?lon=4.76595lat=47.40815zoom=9fullscreen=true On voit qu'a certains endroits il n'y a pas de admin level (en gris sur la carte) il y a aussi des endroit ou les way des relations ne possède aucun tag : http://www.itoworld.com/map/2?lon=1.92736lat=48.24036zoom=10fullscreen=true Whaouu, ils ont vraiment des cartes sur tout chez ITO oO Je me posais justement la question suite à mes multiples modifications, nettoyage, corrections, suppressions sur les communes et leurs limites et à la constatation de nombreux manques. Je dirais qu'en théorie boundary=administrative, admin_level=x et surtout border_type=* ne sert à rien sur les ways pour garantir la cohérence de la base puisque ces informations ne sont importantes que dans les relations. Elles sont sans aucun doute un héritage du passé... Cependant, dans la pratique, j'imagine que ces balises servent encore à simplifier le rendu des limites administratives en évitant des calculs trop lourd. (appli GPS embarqué ou sur smartphone) Si quelqu'un pouvait confirmer par des exemples... Sinon leur suppression permettrait de gagner quelques dizaines de Mo sur un maillage aussi fin que la France ! Près de 130 000 ways sont concernés... Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] way des limites administratives
L'avis de la fourmi, déjà donné il y a pas longtemps sur le layer=0 : L'ordinateur n'en a pas (et encore…) besoin. Le contributeur, si. Voir au premier coup d'œil une balise boundary=administrative (et à mon avis, admin_level=…, mais ça peut être discuté), ça facilite la tâche. Et ça permet de faire fonctionner les filtres dans JOSM (je ne sais pas si les filtres peuvent remonter jusqu'aux balises des relations utilisant les ways…). Quand à l'argument de la taille, les spécialistes répondent toujours que c'est un faux problème. Je les laisserai le dire ici. (border_type, c'est pas abandonné, des fois ?) JB. Le 26/12/2013 19:29, Christophe Merlet a écrit : Le 26/12/2013 19:08, Jérôme Amagat a écrit : Petite question suite a une carte vu sur ito map : Faut il que les tag admin level se trouve sur les way des limites communales obligatoirement? Je suis tombé sur la carte ito map des limites admin http://www.itoworld.com/map/2?lon=4.76595lat=47.40815zoom=9fullscreen=true On voit qu'a certains endroits il n'y a pas de admin level (en gris sur la carte) il y a aussi des endroit ou les way des relations ne possède aucun tag : http://www.itoworld.com/map/2?lon=1.92736lat=48.24036zoom=10fullscreen=true Whaouu, ils ont vraiment des cartes sur tout chez ITO oO Je me posais justement la question suite à mes multiples modifications, nettoyage, corrections, suppressions sur les communes et leurs limites et à la constatation de nombreux manques. Je dirais qu'en théorie boundary=administrative, admin_level=x et surtout border_type=* ne sert à rien sur les ways pour garantir la cohérence de la base puisque ces informations ne sont importantes que dans les relations. Elles sont sans aucun doute un héritage du passé... Cependant, dans la pratique, j'imagine que ces balises servent encore à simplifier le rendu des limites administratives en évitant des calculs trop lourd. (appli GPS embarqué ou sur smartphone) Si quelqu'un pouvait confirmer par des exemples... Sinon leur suppression permettrait de gagner quelques dizaines de Mo sur un maillage aussi fin que la France ! Près de 130 000 ways sont concernés... Librement, ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] way des limites administratives
Le 26/12/2013 19:37, JB a écrit : L'avis de la fourmi, déjà donné il y a pas longtemps sur le layer=0 : L'ordinateur n'en a pas (et encore…) besoin. Le contributeur, si. Voir au premier coup d'œil une balise boundary=administrative (et à mon avis, admin_level=…, mais ça peut être discuté), ça facilite la tâche. Oui et non. On peut aussi considérer que trop de balises redondantes sur tous les objets rends la tache des contributeurs plus laborieuses et fastidieuses en ne sachant plus faire la distinction entre indispensable et facultatif. Sans compter que ça met la barre très haut pour le novice qui se penche sur le projet. A noter que JOSM utilise les informations de la relation pour le rendu. Qu'en est il de id et potlatch. Et ça permet de faire fonctionner les filtres dans JOSM (je ne sais pas si les filtres peuvent remonter jusqu'aux balises des relations utilisant les ways…). Il faudrait un plugin ouvrant un formulaire convivial de recherche à la Overpass API en-ligne et hors-ligne. Ça permet de faire des requêtes sur les affiliation relation-way-node. Quand à l'argument de la taille, les spécialistes répondent toujours que c'est un faux problème. Je les laisserai le dire ici. Faut quand même des gros PC pour travailler sur ces jeux de données. L'extract OSM des relations de communes faisait 33295581 octets. Après nettoyage partiel des relations, c'est passé à 32091671 soit plus d'un Mo gagné. Et pour travailler sur ce fichier, JOSM a atteint la mite des 3Go que je lui accorde :/ (border_type, c'est pas abandonné, des fois ?) Surement. d'autant plus que des valeur comme commune, arrondissement, departement n'ont aucun sens dans la base. Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] way des limites administratives
boundary=administrative me semble souhaitable pour la lisibilité admin_level... ça se discute déjà car en pratique il y a plusieurs niveaux qui peuvent utiliser la même limite. Les rendus ne peuvent pas s'appuyer là dessus, il y a bien trop de limites sans admin_level=*. border_type ? à la lecture du wiki http://wiki.openstreetmap.org/wiki/Key:border_type c'est une balise fourre-tout donc au final inutilisable Tu n'a pas parlé des name, des left/right, etc... tout ça est arbitraire (quel name choisir ?) et pour les left/right ça doit être bourré d'erreurs car je doute que ça soit mis à jour lorsqu'on modifié éventuellement l'orientation d'un way. Entre arbitraire et pas à jour, ça n'est pas exploitable en automatique... et si on en a besoin, on peut le recalculer (même si c'est pas trivial). Le 26 décembre 2013 19:57, Christophe Merlet red...@redfoxcenter.org a écrit : Le 26/12/2013 19:37, JB a écrit : L'avis de la fourmi, déjà donné il y a pas longtemps sur le layer=0 : L'ordinateur n'en a pas (et encore…) besoin. Le contributeur, si. Voir au premier coup d'œil une balise boundary=administrative (et à mon avis, admin_level=…, mais ça peut être discuté), ça facilite la tâche. Oui et non. On peut aussi considérer que trop de balises redondantes sur tous les objets rends la tache des contributeurs plus laborieuses et fastidieuses en ne sachant plus faire la distinction entre indispensable et facultatif. Sans compter que ça met la barre très haut pour le novice qui se penche sur le projet. A noter que JOSM utilise les informations de la relation pour le rendu. Qu'en est il de id et potlatch. Et ça permet de faire fonctionner les filtres dans JOSM (je ne sais pas si les filtres peuvent remonter jusqu'aux balises des relations utilisant les ways…). Il faudrait un plugin ouvrant un formulaire convivial de recherche à la Overpass API en-ligne et hors-ligne. Ça permet de faire des requêtes sur les affiliation relation-way-node. Quand à l'argument de la taille, les spécialistes répondent toujours que c'est un faux problème. Je les laisserai le dire ici. Faut quand même des gros PC pour travailler sur ces jeux de données. L'extract OSM des relations de communes faisait 33295581 octets. Après nettoyage partiel des relations, c'est passé à 32091671 soit plus d'un Mo gagné. Et pour travailler sur ce fichier, JOSM a atteint la mite des 3Go que je lui accorde :/ (border_type, c'est pas abandonné, des fois ?) Surement. d'autant plus que des valeur comme commune, arrondissement, departement n'ont aucun sens dans la base. Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] way des limites administratives
Le 26/12/2013 20:21, Christian Quest a écrit : boundary=administrative me semble souhaitable pour la lisibilité admin_level... ça se discute déjà car en pratique il y a plusieurs niveaux qui peuvent utiliser la même limite. Les rendus ne peuvent pas s'appuyer là dessus, il y a bien trop de limites sans admin_level=*. border_type ? à la lecture du wiki http://wiki.openstreetmap.org/wiki/Key:border_type c'est une balise fourre-tout donc au final inutilisable Je vais les faire disparaitre alors... en tout cas ceux qui concerne les boundary administrative . Et conservé pour les boundary maritime. Tu n'a pas parlé des name, des left/right, etc... tout ça est arbitraire (quel name choisir ?) et pour les left/right ça doit être bourré d'erreurs car je doute que ça soit mis à jour lorsqu'on modifié éventuellement l'orientation d'un way. Non non, ya plus d'erreurs avec les left/right, je les ai tous viré ;o) C'était absolument inutilisé et inutilisable. Avec quelques dommages collatéraux aux frontières de la France... Entre arbitraire et pas à jour, ça n'est pas exploitable en automatique... et si on en a besoin, on peut le recalculer (même si c'est pas trivial). Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] way des limites administratives
Si on regarde la carte ito map on peut voir que beaucoup de pays utilise les admin level sur les way. Je suis pas sur que de tout supprimé soit la bonne solution. Le 26 décembre 2013 20:37, Christophe Merlet red...@redfoxcenter.org a écrit : Le 26/12/2013 20:21, Christian Quest a écrit : boundary=administrative me semble souhaitable pour la lisibilité admin_level... ça se discute déjà car en pratique il y a plusieurs niveaux qui peuvent utiliser la même limite. Les rendus ne peuvent pas s'appuyer là dessus, il y a bien trop de limites sans admin_level=*. border_type ? à la lecture du wiki http://wiki.openstreetmap.org/wiki/Key:border_type c'est une balise fourre-tout donc au final inutilisable Je vais les faire disparaitre alors... en tout cas ceux qui concerne les boundary administrative . Et conservé pour les boundary maritime. Tu n'a pas parlé des name, des left/right, etc... tout ça est arbitraire (quel name choisir ?) et pour les left/right ça doit être bourré d'erreurs car je doute que ça soit mis à jour lorsqu'on modifié éventuellement l'orientation d'un way. Non non, ya plus d'erreurs avec les left/right, je les ai tous viré ;o) C'était absolument inutilisé et inutilisable. Avec quelques dommages collatéraux aux frontières de la France... Entre arbitraire et pas à jour, ça n'est pas exploitable en automatique... et si on en a besoin, on peut le recalculer (même si c'est pas trivial). Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] way des limites administratives
Le 26/12/2013 19:29, Christophe Merlet a écrit : Le 26/12/2013 19:08, Jérôme Amagat a écrit : Petite question suite a une carte vu sur ito map : Faut il que les tag admin level se trouve sur les way des limites communales obligatoirement? Je suis tombé sur la carte ito map des limites admin http://www.itoworld.com/map/2?lon=4.76595lat=47.40815zoom=9fullscreen=true On voit qu'a certains endroits il n'y a pas de admin level (en gris sur la carte) il y a aussi des endroit ou les way des relations ne possède aucun tag : http://www.itoworld.com/map/2?lon=1.92736lat=48.24036zoom=10fullscreen=true Whaouu, ils ont vraiment des cartes sur tout chez ITO oO Je me posais justement la question suite à mes multiples modifications, nettoyage, corrections, suppressions sur les communes et leurs limites et à la constatation de nombreux manques. Je dirais qu'en théorie boundary=administrative, admin_level=x et surtout border_type=* ne sert à rien sur les ways pour garantir la cohérence de la base puisque ces informations ne sont importantes que dans les relations. Elles sont sans aucun doute un héritage du passé... Pour la cohérence, ces balises ne sont pas nécessaires, sauf que, la frontière, c'est le way... De fait, pour la cohérence sémantique : on tagge en boundary les surfaces (relations avec rôles outer de plus en plus fréquents sur les collectivités territoriales), et ce n'est pas très cohérent ! Le tag admin_level n'est pas (très) intéressant sur les ways. mais le tag boundary l'est. Et peut-être qu'un jour on aura un autre tag pour dire entité administrative pour la relation. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] way des limites administratives
Le 26/12/2013 20:59, Jérôme Amagat a écrit : Si on regarde la carte ito map on peut voir que beaucoup de pays utilise les admin level sur les way. Je suis pas sur que de tout supprimé soit la bonne solution. Je parlais juste de border_type qui est très peu et mal utilisé. Pour le reste, il vaut mieux compléter, mais pour quel usage ? Le 26 décembre 2013 20:37, Christophe Merlet red...@redfoxcenter.org mailto:red...@redfoxcenter.org a écrit : Le 26/12/2013 20:21, Christian Quest a écrit : boundary=administrative me semble souhaitable pour la lisibilité admin_level... ça se discute déjà car en pratique il y a plusieurs niveaux qui peuvent utiliser la même limite. Les rendus ne peuvent pas s'appuyer là dessus, il y a bien trop de limites sans admin_level=*. border_type ? à la lecture du wiki http://wiki.openstreetmap.org/__wiki/Key:border_type http://wiki.openstreetmap.org/wiki/Key:border_type c'est une balise fourre-tout donc au final inutilisable Je vais les faire disparaitre alors... en tout cas ceux qui concerne les boundary administrative . Et conservé pour les boundary maritime. Tu n'a pas parlé des name, des left/right, etc... tout ça est arbitraire (quel name choisir ?) et pour les left/right ça doit être bourré d'erreurs car je doute que ça soit mis à jour lorsqu'on modifié éventuellement l'orientation d'un way. Non non, ya plus d'erreurs avec les left/right, je les ai tous viré ;o) C'était absolument inutilisé et inutilisable. Avec quelques dommages collatéraux aux frontières de la France... Entre arbitraire et pas à jour, ça n'est pas exploitable en automatique... et si on en a besoin, on peut le recalculer (même si c'est pas trivial). Librement, -- Christophe Merlet (RedFox) _ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.__org/listinfo/talk-fr https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOYEUX LE(ar)NO(sm)
Le 26/12/2013 15:36, Patrik.ulrich a écrit : Bonjour, J'ai besoin d'une aide. En tant qu'administrateur du site http://belfort-montbeliard.mondio16.com/mini_sites/notredame-belchamp/, je tente de télécharger une carte OSM des communes de Mandeure et Valentigney (contour administratif de ces deux communes) que je nommerais Paroisse Notre-Dame de Belchamp afin d'y indiquer les lieux et l'incorporer dans ce site à la place de l'image google. Bonsoir La paroisse Notre-Dame de Belchamp est déjà cartographiée dans OSM. Il n'est donc pas nécessaire de refaire le travail. http://www.openstreetmap.org/relation/1849735#map=12/47.4450/6.8160 Plusieurs lieux de culte sont aussi déjà bien renseignés. Avec umap, il est possible de faire une carte de ce type. http://umap.openstreetmap.fr/fr/map/notre-dame-de-belchamp_3595#11/47.4462/6.8637 Normalement, le profil de la paroisse devrait s'y afficher avec un de ces deux fichiers (geojson ou osm) : http://frvipofm.net/osm/data/France/ Mais ça ne marche pas et je ne sais pas pourquoi... Je n'arrive d'ailleurs plus à éditer le premier layer. Bug dans umap ? -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Diocèses et autres découpages religieux
Le 7 juin 2012 15:22, Vincent Pottier vpott...@gmail.com a écrit : JOSM affiche les communes et les paroisses de la même façon ? C'est peut-être JOSM qu'il faut changer... -- FrViPofm Le temps semble venu: http://josm.openstreetmap.de/ticket/9478 :) Tu peux argumenter en faveur de ton modèle dans les commentaires ? Depuis le temps, avec le recul, est-ce que tu penses qu'il est correct pour un usage international ? A+ Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Diocèses et autres découpages religieux
Le 7 juin 2012 15:22, Vincent Pottier vpott...@gmail.com a écrit : Le 07/06/2012 11:05, Philippe Verdy a écrit : Le 7 juin 2012 10:08, Ab_fabgamma@gmail.com a écrit : As-tu des exemples à nous présenter ? Regarde en Franche-Comté. Il se peut que j'ai fait des erreurs : avoir mis un tag boundary=administrative au lieu d'un boundary=religious_administration, il se peut... Cependant je viens de faire un test sur ma copie locale de geofabrik France, je ne trouve aucun cas de polygone ayant les tags ref:CEF=* , admin_level=* boundary=administrative (ma copie date d'une semaine environ). Mais peut-être y en a-t-il quelque part... en Franche-Comté... Les références seraient précieuses pour que je puisse corriger. On peut changer le tag boundary=religious_administration en boundary=religious, mais je ne vois pas bien le gain. Non je ne vois aucun gain non plus de ce côté là et ce n'est pas ce que je demande. De plus la réalité cartographiée est (voudrait être) une réalité administrative plutôt que théologique ou religieuse (qui n'a pas sa place dans OSM), d'où mon usage de religious_administration et le ré-emploi de admin_level plutôt qu'un religious_level (procédure de canonisation : vénérable, bienheureux, saint ?). C'est justement la surcharge de admin_level pour ce qui n'a strictement rien d'administratif (et en tout cas est très loin d'être internationalisable, car les structures religieuses sont extrèmement volatiles et les organisations très variables selon les pays et les statuts civils que ces divisions religieuses pourraient avoir (ou ne pas avoir), ou pourraient avoir en partage avec d'autres églises ou religions (par exemple si un diocèse ou un autre niveau dispose d'une fonction locale d'état-civil ou de mission judiciaire). Laissons les divisions religieuses propres à chacune, et certainement pas structurées hérarchiquement comme les division adminsitratives. Les niveaux ne sont pas comparables. Même en France, entre l'Alsace-Moselle (avec le statut spécial) par rapport au reste du territoire, ou peut-être en outre-mer avec les statuts de droit local. Même au sein de la seule église catholique il existe plusieurs congrégations dont les territoires se recouvrent, aucune n'ayant l'autorité sur le territoire qu'elle couvre. La hiérarchie de l'église n'a strictement rien de territorial elle est spirituelle et les limites sont en fait assez floues (et de plus en plus du fait de la réduction des personnels du clergé et des vocations : les diocèses sont souvent regroupés dynamiquement en fonction des disponibilités des prètres, mais 'ifluent pas pour autant sur l'autorité des groupes monastiques ; et de plus en plus d'églises tendent à regrouper leurs activités y compris avec d'autres religions, chrétiennes ou pas, via des groupes interreligieux ou des groupes de réflexion laïques). Même dans les pays où les structures d'églises sont encore fortes et disposent de certaines autorités civiles reconnues (Pologne, Russie, Royaume-Uni, Irlande, Etats-Unis) la hiérarchisation des déoupages territoriaux n'a aucun sens (en comparaison des hiérarchies religieuses qui ne souvent pas le même moule et qui continuent à perpétuer des traditions anciennes de type autorité morale, même si elles sont été déplacées ou ont émigré dans d'autres territoires ou si depuis les pays hotes ont connu de larges bouleversements civils et administratifs). Donc admin_level=8 n'a pas de sens pour moi (il a été imposé au forcing en France, en commençant d'abord par l'Alsace-Moselle dans le cadre du concordat qui n'existe que là et pas ailleurs en France). On est très loin d'avoir même discuté de ça à une échelle plus large ou internationale. Ce devrait être catholic_level=diocèse (valeur peut-être à indiquer en latin... sauf que depuis le concile de Vatican II le latin n'est plus officiel pour le culte qu'au Vatican, les langues nationales et régionales étant favorisées), voire catholic_level=FR:diocèse si la structure ne fonctionne qu'en France (dans d'autres pays il peut y avoir plus ou moins de niveaux, et il existe des structures largement transfrontalières aussi dans les pays où l'église est très minoritaire). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Diocèses et autres découpages religieux
Le 26/12/2013 22:15, Vincent Privat a écrit : Le 7 juin 2012 15:22, Vincent Pottier vpott...@gmail.com mailto:vpott...@gmail.com a écrit : JOSM affiche les communes et les paroisses de la même façon ? C'est peut-être JOSM qu'il faut changer... -- FrViPofm Le temps semble venu: http://josm.openstreetmap.de/ticket/9478 :) Tu peux argumenter en faveur de ton modèle dans les commentaires ? Depuis le temps, avec le recul, est-ce que tu penses qu'il est correct pour un usage international ? A+ Vincent Pour l'Église catholique, ça marche. Il y aura forcément des exceptions, des endroits où ça coince... Je ne connais pas suffisamment pas le fonctionnement des autres Église chrétiennes ou des autres religions. Je vois que le tag boundary=religious_administration est repris avec un admin_level à divers endroits en France, ainsi qu'en Autriche, au Québec pour l'Église catholique, et même en Malaisie (bon, je ne suis pas sur que ce soit bien employé, là bas). Mais aussi en Ukraine pour l'Église orthodoxe. Et, comme il y a de la donnée, il commence à y avoir de la demande... Ça, on ne trouve pas sur la carte G* -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Diocèses et autres découpages religieux
Le 27/12/2013 02:23, Philippe Verdy a écrit : C'est justement la surcharge de admin_level pour ce qui n'a strictement rien d'administratif Et bien si justement... Tu les trouve où les actes de baptême, de mariage, d'enterrement ? Tu veux que je te montre des registres ? (et en tout cas est très loin d'être internationalisable, car les structures religieuses sont extrèmement volatiles et les organisations très variables selon les pays et les statuts civils que ces divisions religieuses pourraient avoir (ou ne pas avoir), ou pourraient avoir en partage avec d'autres églises ou religions (par exemple si un diocèse ou un autre niveau dispose d'une fonction locale d'état-civil ou de mission judiciaire). Peut-être pas si volatiles que le ECPI... Je connais des diocèses qui sont pas loin de fêter leurs 2000 ans ! Laissons les divisions religieuses propres à chacune, et certainement pas structurées hérarchiquement comme les division adminsitratives. Les niveaux ne sont pas comparables. Ah bon ? Il s'est inspiré de quoi Napoléon ? Il a eu un trait de génie ? Non, il a copié-collé... ou presque. On est allé le chercher où le schéma d’administration du territoire pour échapper aux comtés, aux baronnies, aux duchés et à tout le tintouin qui relevait de la noblesse ? Même en France, entre l'Alsace-Moselle (avec le statut spécial) par rapport au reste du territoire, ou peut-être en outre-mer avec les statuts de droit local. Même au sein de la seule église catholique il existe plusieurs congrégations dont les territoires se recouvrent, aucune n'ayant l'autorité sur le territoire qu'elle couvre. Là je crois que tu mélanges les choses... Tu mélanges la vie associative et les collectivité territoriales, la vie religieuse et l'organisation des diocèses. La hiérarchie de l'église n'a strictement rien de territorial elle est spirituelle et les limites sont en fait assez floues Hum... Mais comme les chrétiens (et les autres) ne vivent pas encore sur des petits nuages, l'Église s'intéresse aussi à des choses au raz des pâquerettes et pour ça, elle s'organise... en territoire. Relis ton code de droit canonique. (et de plus en plus du fait de la réduction des personnels du clergé et des vocations : les diocèses sont souvent regroupés dynamiquement en fonction des disponibilités des prètres, mais 'ifluent pas pour autant sur l'autorité des groupes monastiques ; Hou, le mélange... Ce n'est pas le maire qui nome le président du club de foot. Ce n'est pas l'évêque qui nome le responsable d'une communauté religieuse. Et puis ça n'a aucun rapport... et de plus en plus d'églises tendent à regrouper leurs activités y compris avec d'autres religions, chrétiennes ou pas, via des groupes interreligieux ou des groupes de réflexion laïques). Là,, je ne vois vraiment pas le rapport. Parce que le Secours Catholique collabore avec le CCAS, parce que l'un et l'autre ont des restrictions budgétaires, parce que Don Camillo et Peppone travaillent ensemble par force, il faudrait supprimer les paroisses et les communes d'OSM ? Même dans les pays où les structures d'églises sont encore fortes et disposent de certaines autorités civiles reconnues (Pologne, Russie, Royaume-Uni, Irlande, Etats-Unis) la hiérarchisation des déoupages territoriaux n'a aucun sens (en comparaison des hiérarchies religieuses qui ne souvent pas le même moule et qui continuent à perpétuer des traditions anciennes de type autorité morale, même si elles sont été déplacées ou ont émigré dans d'autres territoires ou si depuis les pays hotes ont connu de larges bouleversements civils et administratifs). Ukraine, ça fait partie de ta liste des églises encore fortes et disposant de certaines autorités civiles reconnues mais où là hiérarchisation des découpages territoriaux n'a aucun sens ? Parce qu'il sont en train de s'y mettre à la cartographie des diocèses dans OSM... Donc admin_level=8 n'a pas de sens pour moi Dommage pour toi. Mais ça m'en dit plus sur ta difficulté à comprendre que sur la faiblesse du schéma. (il a été imposé au forcing en France, en commençant d'abord par l'Alsace-Moselle dans le cadre du concordat qui n'existe que là et pas ailleurs en France). On est très loin d'avoir même discuté de ça à une échelle plus large ou internationale. Effectivement. J'ai commencé tout seul. Mais pas en Alsace-Moselle. Et honnêtement je n'ai imposé à personne de cartographier quoi que ce soit. J'ai un peu obligé Sly, il y a quelques temps, à ajouter un peu de rigueur dans ses requêtes pour layers.osm.fr. Mais il n'est pas rancunier. Ce devrait être catholic_level=diocèse (valeur peut-être à indiquer en latin... sauf que depuis le concile de Vatican II le latin n'est plus officiel pour le culte qu'au Vatican, Là encore, c'est un peu n'importe quoi... Mais, bon... Si tu en pers ton latin, on t'excusera. les langues nationales et régionales étant favorisées), voire catholic_level=FR:diocèse si la structure ne
Re: [OSM-talk-fr] Diocèses et autres découpages religieux
Le 27 décembre 2013 03:28, Vincent Pottier vpott...@gmail.com a écrit : Là je crois que tu mélanges les choses... Tu mélanges la vie associative et les collectivité territoriales, la vie religieuse et l'organisation des diocèses. Non tu interprètes ce que je dis à ta guise. La hiérarchie de l'église n'a strictement rien de territorial elle est spirituelle et les limites sont en fait assez floues Hum... Mais comme les chrétiens (et les autres) ne vivent pas encore sur des petits nuages, l'Église s'intéresse aussi à des choses au raz des pâquerettes et pour ça, elle s'organise... en territoire. Relis ton code de droit canonique. Le droit canonique ne s'occupe pas des territoires, et ce n'est pas le sujet. (et de plus en plus du fait de la réduction des personnels du clergé et des vocations : les diocèses sont souvent regroupés dynamiquement en fonction des disponibilités des prètres, mais 'ifluent pas pour autant sur l'autorité des groupes monastiques ; Hou, le mélange... Ce n'est pas le maire qui nome le président du club de foot. Ce n'est pas l'évêque qui nome le responsable d'une communauté religieuse. Et puis ça n'a aucun rapport... Effectivement mais là tu introduis toi-même ces mélanges de tout avec n'importe quoi. Je n'ai jamais parlé de club de foot. Juste de la notion de hiérarchie religieuses qui n'est pas du tout territoriale puisque les diverses congrégations se revouvrent ; l'église même si elle reconnait une même autorité spirituelle, admet aussi la multiplicité des congrégations et traditions et pratiques. Et celles-ci sont de moins en moins attachées à un territoire, les différentes branches sont presque toutes internationales. Aucune église n'est plus propriétaire de ses ouailles. Chaque mouvement dans l'église peut aller les chercher sur le territoire du voisin et sinon collaborer avec des groupes très lointains géographiquement. et de plus en plus d'églises tendent à regrouper leurs activités y compris avec d'autres religions, chrétiennes ou pas, via des groupes interreligieux ou des groupes de réflexion laïques). Là,, je ne vois vraiment pas le rapport. Parce que tu ne veux pas lire. Parce que le Secours Catholique collabore avec le CCAS, parce que l'un et l'autre ont des restrictions budgétaires, parce que Don Camillo et Peppone travaillent ensemble par force, il faudrait supprimer les paroisses et les communes d'OSM ? Tu interprètes, je n'ai pas dit ça, mais les hiérarchies de niveaux territoriaux n'ont aucun sens dans l'église, même catholique en France. la structure des archevéches, évéchés, diocèses, doyennés, paroisses colle aujourd'hui très mal avec la réalité alors que ce qui subsiste c'est surtout une question d'autorité morale, et que cette autorité n'est plus attaché à un territoire particulier. C'est vrai aussi dans l'islam ou l'orthodoxie. La notion de territoire est une affaire terrestre loin des préoccupations religieuses (et encore plus en France où l'église ne possède pratiquement plus ses lieux de culte (et ne compte d'ailleurs même pas les récupérer, étant trop contente de pouvoir en disposer gratuitement avec l'entretien assuré par les collectivités). Dommage pour toi. Mais ça m'en dit plus sur ta difficulté à comprendre que sur la faiblesse du schéma. Tu présupposes que je ne comprends pas. J'ai parfaitement compris que ton idée c'est de mélanger les choux et les carottes parce que ça t'arrange bien pour ce que tu veux faire des données. JE suis opposé à ces mélanges entre notions qui ne sont pas liées ensemble et pas maintenues ensemble. (il a été imposé au forcing en France, en commençant d'abord par l'Alsace-Moselle dans le cadre du concordat qui n'existe que là et pas ailleurs en France). On est très loin d'avoir même discuté de ça à une échelle plus large ou internationale. Effectivement. J'ai commencé tout seul. Mais pas en Alsace-Moselle. Ce devrait être catholic_level=diocèse (valeur peut-être à indiquer en latin... sauf que depuis le concile de Vatican II le latin n'est plus officiel pour le culte qu'au Vatican, Là encore, c'est un peu n'importe quoi... Comme ta réponse d'ailleurs qui mélange tout, réinterprète tout meˆme sur ce que je n'ai pas dit. Mais, bon... Si tu en pers ton latin, on t'excusera. Déjà tu perds le sens du français, en inventant un javanais comme on invente un jargon administratif pour classer des choses dont l'administration française ne s'occupe pas du tout et ne dit même pas s'occuper (sauf en Alsace-Moselle). les langues nationales et régionales étant favorisées), voire catholic_level=FR:diocèse si la structure ne fonctionne qu'en France Et il semblerait qu'elle fonctionne ailleurs. D'ailleurs on ne va pas changer les boundary=administrative + admin_level=8 en boundary=administrative + territorial_level=FR:commune sous prétexte que les Allemands ont un système un peu différent. Là encore je n'ai pas demandé ça ! Les structures
Re: [OSM-ja] Planning import: Urayasu Bulding Outline/浦安市の建物形状
いいだです。 本件、建物形状のインポート作業が終わりました。 ありがたいことに、既存データ、および提供いただいたデータのクオリティが素晴らしく高く、 作業に際して大きなトラブルは無かった印象です。 (すべて妥当性検証しながら行いましたが、道路の修正もほとんど不要でした) 作業内容について、いくつかご報告です。 * 既存データとのマージについて なるべく既存のデータを残すようにインポートを行いましたが、 以下の観点でインポート用データを優先している箇所がいくつかあります。 1. 既存データがKIBAN/NAROを利用しており、なおかつBing画像(2011年くらい)と比べても、既存データの情報が古いと思われる場合 2. 非常に複雑な形状の建物など、既存データの修正が大きく困難な場合 具体的には、大きなショッピングモールや、大型の病院などです。 なるべく既存データを(一部でも)使うようにしましたが、非常に困難な場合はインポートデータに入れ替えています。 もちろんその場合でも、タグ情報は移行していますのでご安心ください。 * その他の事項 1. インポートデータの中にあった、堅牢建築物(building:material=concrete)は、 既存の建物データへタグを付与しています。 2. 舞浜地区(≒ディズニーランド、シー)は、インポートに関連する作業を行っていません。 (building:materialタグも付与していません) 舞浜地区は、既存データの量が格段に詳細であり、なおかつ、 僕の目視確認レベルではありますが、インポートが必要そうな建物データが ポップコーン売店レベルの小さな建物ばかりだったためです。 なので、舞浜地域については基盤地図を利用してのトレースなどで位置調整、 それからもちろん、敷地内での実測Survey :) で情報を補うのがよいのかな、と思っています。 * 今後の予定 ひとまず、本インポートの関連作業は完了にしたいと思います。 本作業に関しての不明点などあれば、僕あるいはMLまでお問い合わせいただければと思います。 * ついでに良かったこと 道路データにも妥当性検証でのエラーがほとんど無かった、ということで、 pgroutingやOSRMなどによる道路ネットワークのテストデータとしても、 この地域のデータはかなり実用になるのではないかと思います。 2013年12月24日 0:43 Satoshi IIDA nyamp...@gmail.com: いいだです。 Imports MLでの話し合いがおおむね落ち着きました。 詳しくはWikiページにまとめていますが、変更点としては、、、 * オブジェクトへのsourceタグ付与をやめました * 変更セットに対して、以下のタグを付与します ** source ** source_ref English: http://wiki.openstreetmap.org/wiki/Import/Catalogue/Urayasu_bld_import Japanese: http://wiki.openstreetmap.org/wiki/JA:Import/Catalogue/Urayasu_bld_import 他はもとの提案のそのままです。 作業は近日中に開始します。 終わったらまたご報告します。 1つ1つの町字ごとにチェックしながら投入するのでほとんど作業重複はないと思うのですが、 不明点あれば僕までご連絡ください。 -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] Planning import: Urayasu Bulding Outline/浦安市の建物形状
ikiyaです。 インポート、既存データとのマージ（私の古いデータもあったりして）お疲れ様でした。 地図拝見しました。道路と建物が揃って充実されよかったと思います。 H25年作成データをインポートされたということで、 基盤地図情報2500（農研さん配信TMS）と重ねて見ましたが 新規のマンションや経年変化の部分も確実にインポートで修正されていました。 その一方、最新データでかつ1/2500の精度良いデータをインポートした為か、 マージして既存データを残した部分に古さが見られたり、 不自然な建物がやや目に留まる感じでした。 （浦安行けたら、現地見て直します。） 何度か浦安マッピングパーティーあったともいますが、また、POIの増加を願って 浦安でマッピングパーティーできればよいですね。 --- On Thu, 2013/12/26, Satoshi IIDA nyamp...@gmail.com wrote: いいだです。 本件、建物形状のインポート作業が終わりました。 ありがたいことに、既存データ、および提供いただいたデータのクオリティが素晴らしく高く、 作業に際して大きなトラブルは無かった印象です。 (すべて妥当性検証しながら行いましたが、道路の修正もほとんど不要でした) 作業内容について、いくつかご報告です。 * 既存データとのマージについて なるべく既存のデータを残すようにインポートを行いましたが、 以下の観点でインポート用データを優先している箇所がいくつかあります。 1. 既存データがKIBAN/NAROを利用しており、なおかつBing画像(2011年くらい)と比べても、既存データの情報が古いと思われる場合 2. 非常に複雑な形状の建物など、既存データの修正が大きく困難な場合 具体的には、大きなショッピングモールや、大型の病院などです。 なるべく既存データを(一部でも)使うようにしましたが、非常に困難な場合はインポートデータに入れ替えています。 もちろんその場合でも、タグ情報は移行していますのでご安心ください。 * その他の事項 1. インポートデータの中にあった、堅牢建築物(building:material=concrete)は、 既存の建物データへタグを付与しています。 2. 舞浜地区(≒ディズニーランド、シー)は、インポートに関連する作業を行っていません。 (building:materialタグも付与していません) 舞浜地区は、既存データの量が格段に詳細であり、なおかつ、 僕の目視確認レベルではありますが、インポートが必要そうな建物データが ポップコーン売店レベルの小さな建物ばかりだったためです。 なので、舞浜地域については基盤地図を利用してのトレースなどで位置調整、 それからもちろん、敷地内での実測Survey :) で情報を補うのがよいのかな、と思っています。 * 今後の予定 ひとまず、本インポートの関連作業は完了にしたいと思います。 本作業に関しての不明点などあれば、僕あるいはMLまでお問い合わせいただければと思います。 * ついでに良かったこと 道路データにも妥当性検証でのエラーがほとんど無かった、ということで、 pgroutingやOSRMなどによる道路ネットワークのテストデータとしても、 この地域のデータはかなり実用になるのではないかと思います。 2013年12月24日 0:43 Satoshi IIDA nyamp...@gmail.com: いいだです。 Imports MLでの話し合いがおおむね落ち着きました。 詳しくはWikiページにまとめていますが、変更点としては、、、 * オブジェクトへのsourceタグ付与をやめました * 変更セットに対して、以下のタグを付与します ** source ** source_ref English: http://wiki.openstreetmap.org/wiki/Import/Catalogue/Urayasu_bld_import Japanese: http://wiki.openstreetmap.org/wiki/JA:Import/Catalogue/Urayasu_bld_import 他はもとの提案のそのままです。 作業は近日中に開始します。 終わったらまたご報告します。 1つ1つの町字ごとにチェックしながら投入するのでほとんど作業重複はないと思うのですが、 不明点あれば僕までご連絡ください。 -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] Planning import: Urayasu Bulding Outline/浦安市の建物形状
いいだです。 既存データを残した部分に古さが見られたり はい、大きなマンションの一部の棟だけ古いデータだったりすると、 拡大した時にちょっと見栄えがよくない部分あるのは確かです。 どうしても気になる場合は、その部分を描いた人との合意が取れれば インポートデータに差し替えしてしまってもよいと思っています。 インポート用のファイルは街区単位になっていてとても扱いやすいので、 osm上でマーカーを置いたURLをいただければ大丈夫です。 そういう意味で言うと、もう一つ悩ましいのは 浦安駅前周辺の建物密集地域の処理です。 基本的にSurveyしたほうがいいだろうな、という認識ですが、 Surveyをするにしても、怪しい部分にアタリをつけるために なにか上手いやり方があるんじゃないかなぁ、とは思っています。 (例えば、OSM上データと、インポート用データをどちらもPostGISに入れて、 「含んでいる面積が90%以上異なる場合」だけを抽出するとか？) マッピングパーティは是非やりたいです :) 2013年12月27日 9:43 ikiya insidekiwi...@yahoo.co.jp: ikiyaです。 インポート、既存データとのマージ（私の古いデータもあったりして）お疲れ様でした。 地図拝見しました。道路と建物が揃って充実されよかったと思います。 H25年作成データをインポートされたということで、 基盤地図情報2500（農研さん配信TMS）と重ねて見ましたが 新規のマンションや経年変化の部分も確実にインポートで修正されていました。 その一方、最新データでかつ1/2500の精度良いデータをインポートした為か、 マージして既存データを残した部分に古さが見られたり、 不自然な建物がやや目に留まる感じでした。 （浦安行けたら、現地見て直します。） 何度か浦安マッピングパーティーあったともいますが、また、POIの増加を願って 浦安で マッピングパーティーできればよいですね。 --- On *Thu, 2013/12/26, Satoshi IIDA nyamp...@gmail.com nyamp...@gmail.com* wrote: いいだです。 本件、建物形状のインポート作業が終わりました。 ありがたいことに、既存データ、および提供いただいたデータのクオリティが素晴らしく高く、 作業に際して大きなトラブルは無かった印象です。 (すべて妥当性検証しながら行いましたが、道路の修正もほとんど不要でした) 作業内容について、いくつかご報告です。 * 既存データとのマージについて なるべく既存のデータを残すようにインポートを行いましたが、 以下の観点でインポート用データを優先している箇所がいくつかあります。 1. 既存データがKIBAN/NAROを利用しており、なおかつBing画像(2011年くらい)と比べても、既存データの情報が古いと思われる場合 2. 非常に複雑な形状の建物など、既存データの修正が大きく困難な場合 具体的には、大きなショッピングモールや、大型の病院などです。 なるべく既存データを(一部でも)使うようにしましたが、非常に困難な場合はインポートデータに入れ替えています。 もちろんその場合でも、タグ情報は移行していますのでご安心ください。 * その他の事項 1. インポートデータの中にあった、堅牢建築物(building:material=concrete)は、 既存の建物データへタグを付与しています。 2. 舞浜地区(≒ディズニーランド、シー)は、インポートに関連する作業を行っていません。 (building:materialタグも付与していません) 舞浜地区は、既存データの量が格段に詳細であり、なおかつ、 僕の目視確認レベルではありますが、インポートが必要そうな建物データが ポップコーン売店レベルの小さな建物ばかりだったためです。 なので、舞浜地域については基盤地図を利用してのトレースなどで位置調整、 それからもちろん、敷地内での実測Survey :) で情報を補うのがよいのかな、と思っています。 * 今後の予定 ひとまず、本インポートの関連作業は完了にしたいと思います。 本作業に関しての不明点などあれば、僕あるいはMLまでお問い合わせいただければと思います。 * ついでに良かったこと 道路データにも妥当性検証でのエラーがほとんど無かった、ということで、 pgroutingやOSRMなどによる道路ネットワークのテストデータとしても、 この地域のデータはかなり実用になるのではないかと思います。 2013年12月24日 0:43 Satoshi IIDA nyamp...@gmail.comhttp://mc/compose?to=nyamp...@gmail.com : いいだです。 Imports MLでの話し合いがおおむね落ち着きました。 詳しくはWikiページにまとめていますが、変更点としては、、、 * オブジェクトへのsourceタグ付与をやめました * 変更セットに対して、以下のタグを付与します ** source ** source_ref English: http://wiki.openstreetmap.org/wiki/Import/Catalogue/Urayasu_bld_import Japanese: http://wiki.openstreetmap.org/wiki/JA:Import/Catalogue/Urayasu_bld_import 他はもとの提案のそのままです。 作業は近日中に開始します。 終わったらまたご報告します。 1つ1つの町字ごとにチェックしながら投入するのでほとんど作業重複はないと思うのですが、 不明点あれば僕までご連絡ください。 -- Satoshi IIDA mail: nyamp...@gmail.com http://mc/compose?to=nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [Talk-ht] [OSM-talk-fr] Christmas Mapping en Haiti, deuxième édition
En revanche, pour une activité collaborative sur place, c'est super de faire ça : l'occasion de ne pas seulement en faire une activité consacrée à OSM, mais aussi un lieu d'échange et de collaboration, partager des repas, visiter les familles en difficulté, relever l'état des terrains et ce qu'on peut faire pour qu'ils passent un Noël un peu décent, etc. Et les informer des lieux de partage pour qu'ils ne restent pas seuls le soir de Noël avec leurs difficultés. Peut-être qu'en fin de compte, l'acticité OSM est un bn prétexte pour déplacer des gens en les intéressant à quelque chose de motivant, et en leur mettant à disposition un matériel qu'ils n'ont pas. On pourrait faire la même chose en France avec les assos de type Restos du Coeur, Croix-Rouge, Armée du Salut, Chaine de l'Espoir, ou avec le SAMU social. Et au delà de l'activité OSM (de mapping ou de formation), prévoir le repas, l'animation avec ces assos et organisations et les soutiens des collectivités locales... Pourraient y venir aussi nombre de personnes seules qu'il faut motiver avec quelque chose à faire et pas seulement à recevoir pour qu'elles sortent de leur isolement social et acceptent certaines formes d'aide. Le 20 décembre 2013 20:47, Severin MENARD severin.men...@gmail.com ___ Talk-ht mailing list Talk-ht@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour traduire les messages.
[Talk-TW] Fw: 計畫生育解禁 單獨二胎開放
發這則的用意是？ 開啟 2013年12月26日 at 下午9:45:18, ~冰寒雪月~ (d69542...@yahoo.com.tw) 寫: 行“單獨二胎”政策，但仍人少部分當局機關私下強行將懷孕婦女拖行至地下醫院進行強摘嬰童手術，由此觀之，政府高層在推行政策時，下轄之地方機關卻未依照高層指導貫徹落實施行方針，這不僅是政策推行階段領導機關與地方當局無法確實銜接，因此導致悲劇不斷發生。 綜上所述，習近平自三中全會後所規劃的“單獨二胎”政策，能否真正造福社會大眾，給予中國的女性同胞生育自由的權利？___ Talk-TW mailing list Talk-TW@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-tw
