Re: [OSM-talk] Out of Service Roads
On Fri, Mar 29, 2013 at 12:51:43AM +, Jaakko Helleranta.com wrote: In Haiti we've usually taken a pretty clear map-it-as-it-is-on-the-ground approach. * storm wipes out a bridge -- the bridge is deleted until a new is built. * a road is damaged so severly that you can only walk it -- it's a path until fixed * a slightly minor damage to the road requires a 4x4 or tractor to drive it -- it's probably downgraded to a track 'till fixed. As always, one has to think if the damage (=change in the map) is long-term enough to justify mapping it vs. How severe the damage (/change) is / how significantly it impacts map (/data) usage, etc. Define long-term. When you look into cat manufacturer supplied satnav systems people drive around with 4-5 year old maps - which are still perfectly okay. If we start tagged ultra-short-term problems the maps cant be put into offline systems like in-dash satnavs. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Out of Service Roads
2013/3/30 Florian Lohoff f...@zz.de Define long-term. I think you can't define this on a global level, it depends heavily on the local activity whether it makes sense to enter a mid-term interruption into OSM or ignore it. When you look into cat manufacturer supplied satnav systems people drive around with 4-5 year old maps - which are still perfectly okay. With OSM-data I wouldn't expect someone to use 4 or 5 year old data on the other hand ;-) If we start tagged ultra-short-term problems the maps cant be put into offline systems like in-dash satnavs. offline systems without updating possibility will always have the problems you get with a single snapshot (e.g. errors introduced by novice mappers or for other reasons and corrected shortly after, e.g. recently we had such a case in the Italian motorway system which caused a deviation for everyone using this motorway (one of two for North-South-connections, so roughly half the long-range traffic). I think we should discourage people from mapping the current state just because it might change in a few months and people using old data and not updating it would have problems, instead I believe that real time data will get even more important than it is already now. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Out of Service Roads
Martin Koppenhoefer dieterdre...@gmail.com writes: 2013/3/30 Florian Lohoff f...@zz.de Define long-term. I think you can't define this on a global level, it depends heavily on the local activity whether it makes sense to enter a mid-term interruption into OSM or ignore it. Agreed that it's tricky, but for right now, I'd say a week is short enough to let something be, and a year is too long. The tricky part is From 2 weeks to 3 months. (That's a US-centric view.) pgpJCwq_g1P4v.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Out of Service Roads
On Sat, Mar 30, 2013 at 01:00:54PM +0100, Martin Koppenhoefer wrote: 2013/3/30 Florian Lohoff f...@zz.de Define long-term. I think you can't define this on a global level, it depends heavily on the local activity whether it makes sense to enter a mid-term interruption into OSM or ignore it. When you look into cat manufacturer supplied satnav systems people drive around with 4-5 year old maps - which are still perfectly okay. With OSM-data I wouldn't expect someone to use 4 or 5 year old data on the other hand ;-) If we start tagged ultra-short-term problems the maps cant be put into offline systems like in-dash satnavs. offline systems without updating possibility will always have the problems you get with a single snapshot (e.g. errors introduced by novice mappers or for other reasons and corrected shortly after, e.g. recently we had such a case in the Italian motorway system which caused a deviation for everyone using this motorway (one of two for North-South-connections, so roughly half the long-range traffic). I think we should discourage people from mapping the current state just because it might change in a few months and people using old data and not updating it would have problems, instead I believe that real time data will get even more important than it is already now. Realtime might be possible in Europe - We have huge areas in the World where realtime is simply impossible due to missing IP infrastructure. And mapping a disruption/destroyed infrastructure is not only a matter of mapping resources but also whether the data is still usable. If there is a local divert - dont delete the bridge if their will be a new one within e.g. 6 Months. The map data with the bridge intact are still usable and fine. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Out of Service Roads
On Sat, Mar 30, 2013 at 08:45:55AM -0400, Greg Troxel wrote: Martin Koppenhoefer dieterdre...@gmail.com writes: I think you can't define this on a global level, it depends heavily on the local activity whether it makes sense to enter a mid-term interruption into OSM or ignore it. Agreed that it's tricky, but for right now, I'd say a week is short enough to let something be, and a year is too long. The tricky part is From 2 weeks to 3 months. (That's a US-centric view.) Its not that complicated IMHO - If the data is still useful with the fault not beeing mapped - and rebuilding the infrastructure is going to happen - let it untouched. If people will need a 300km divert to get over the river, and the bridge will not be replaced due to economic reasons its a different thing. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM Monster
OSM data turned into a monster! http://vimeo.com/62468031 -- Martijn van Exel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-it] errore nel Indoor Mapping di un Centro Commerciale
forse ottimo, ma di sicuro lungo xD comunque sia per migliorare il piano terra e creare il secondo piano vorrei l'utilizzare la loro mappa online (che è la stessa dei tabelloni dentro il C.C.). ho già contattato l'ufficio informazione del C.C. che mi ha informato di aver girato la pratica all'ufficio competente (credo sia quello legale). ho anche chiesto l'autorizzazione a pubblicare i numeri di telefono e nomi delle varie attività commerciali; non dovrebbero esserci problemi legali, ma preferisco chiedere anche solo per una questione di cortesia e comunque per sicurezza mia e del progetto oltre che del CC stess). per quanto riguarda le note legali sulla mappa sono abbastanza sicuro che il detentore dei diritti dellaplanimetria del centro commerciale (almeno quella semplificata dei tabelloni informativi) non sia l'architetto ma il centro commerciale stesso. sempre per chiarire: proprio perchè non sapevo quale fosse il limite nell'utilizzo della immagine ho preferito usarla solo per confronto con il bozzetto e solo per cancellare le parti che non assomigliavano (quindi nessuna correzione o ispirazione dall'immagine scattata per realizzare il bozzetto) dovrei essere abbastanza al sicuro da questo punto di vista, ma non è detto (motivo per cui nella mail ho dato rassicurazioni che avrei eliminato qualsiasi elemento a loro non fosse andato bene.) avrei dovuto farlo da subito...purtroppo non c'ho proprio pensato :( speriamo bene. -- View this message in context: http://gis.19327.n5.nabble.com/errore-nel-Indoor-Mapping-di-un-Centro-Commerciale-tp5754060p5755218.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Da domani scatta l'open by default sui siti italiani
2013/3/18 Maurizio Napolitano napoo...@gmail.com Da http://www.dati.gov.it/content/monitoraggio-sullo-stato-dellopen-data-italia-dopo-lopen-default [..] A partire dal 18 marzo 2013, scadenza dei novanta giorni previsti dalla Legge, dati e documenti pubblicati online dalle amministrazioni titolari - senza una esplicita licenza d’uso che ne definisca le possibilità e i limiti di riutilizzo – sono da intendersi come dati aperti, quindi dati che possono essere liberamente acquisiti da chiunque e riutilizzabili anche per fini commerciali. Il concetto di open data, inteso come subset del più ampio concetto di PSI (public sector information), nel contesto italiano assume un rilievo molto più evidente, i due concetti diventano per certi versi molto vicini tra loro. Pertanto, potrei prendere la seguente piantina che è stata pubblicata sul sito del comune di Gattinara per informare i cittadini dei cambi alla viabilità e inserire i dati in OSM? http://comune.gattinara.vc.it/FileDownload.asp?T=4I=21251 Al momento la situazione su OSM lascia molto a desiderare http://qa.poole.ch/?zoom=15lat=45.61341lon=8.37275layers=TFFB0 Ciao, Andrea. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] errore nel Indoor Mapping di un Centro Commerciale
2013/3/30 Aury88 spacedrive...@gmail.com ho già contattato l'ufficio informazione del C.C. che mi ha informato di aver girato la pratica all'ufficio competente (credo sia quello legale). vediamo cosa ti dicono, probabilmente anche essendo il dipartimento legale non saranno esperti nel campo di intellectual property, e forse ho anche tolto (i dettagli della interpretazione di diritti d'autore dipendono probabilmente da casi precedenti risolti in tribunale, ed è ben possibile che i tribunali di un paese hanno deciso diversamente dai tribunali in un altra paese). ho anche chiesto l'autorizzazione a pubblicare i numeri di telefono e nomi delle varie attività commerciali; e cosa fai se ti dicono di no, cioè ti vietano una cosa di cui forse non hanno il diritto di vietartela? per quanto riguarda le note legali sulla mappa sono abbastanza sicuro che il detentore dei diritti dellaplanimetria del centro commerciale (almeno quella semplificata dei tabelloni informativi) non sia l'architetto ma il centro commerciale stesso. se tu fai una foto di una scultura protetta di diritti di copyright, hai tu i diritti della foto? No, al meno che la scultura non è solo attinenza. Anche in Italia sono protetti dell'architettura: i disegni e le opere dell'architettura, le opere del disegno industrialehttp://it.wikipedia.org/wiki/Disegno_industriale che presentino carattere creativo e valore artistico; (wikipedia: http://it.wikipedia.org/wiki/Diritto_d%27autore_italiano ) sempre per chiarire: proprio perchè non sapevo quale fosse il limite nell'utilizzo della immagine ho preferito usarla solo per confronto con il bozzetto e solo per cancellare le parti che non assomigliavano (quindi nessuna correzione o ispirazione dall'immagine scattata per realizzare il bozzetto) dovrei essere abbastanza al sicuro da questo punto di vista, ma non è detto (motivo per cui nella mail ho dato rassicurazioni che avrei eliminato qualsiasi elemento a loro non fosse andato bene.) avrei dovuto farlo da subito...purtroppo non c'ho proprio pensato :( speriamo bene. non ti preoccupare, non credo che si creeranno problemi per quanto loro dovrebbero aver interesse di diffondere il loro C.C. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] errore nel Indoor Mapping di un Centro Commerciale
Ehehe, in alcuni vicoli di Genova contavo i passi tra gli sguardi stupiti delle prostitute :-)) Nei centri commerciali solitamente usano pavimentare con le piastrelle da 60cm (se messe in diagonale 84,6cm): basta contare quelle e ottieni una misura più precisa. Alessandro Il giorno Fri, 29 Mar 2013 02:37:03 -0700 (PDT) Aury88 spacedrive...@gmail.com ha scritto: bella domanda! Io ho usato il vecchio metodo: contando il numero di passi (sembravo un pazzo) ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] errore nel Indoor Mapping di un Centro Commerciale
Am 30/mar/2013 um 14:02 schrieb Alessandro ale_z...@libero.it: Nei centri commerciali solitamente usano pavimentare con le piastrelle da 60cm (se messe in diagonale 84,6cm): basta contare quelle e ottieni una misura più precisa. anche con un laser disto si può operare, sopratutto quando sei in due e l'altro tiene un foglio di carta da puntare il punto di misurazione... ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] errore nel Indoor Mapping di un Centro Commerciale
Il 30/03/2013 14:02, Alessandro ha scritto: Ehehe, in alcuni vicoli di Genova contavo i passi tra gli sguardi stupiti delle prostitute :-)) Nei centri commerciali solitamente usano pavimentare con le piastrelle da 60cm (se messe in diagonale 84,6cm): basta contare quelle e ottieni una misura più precisa. Interessante il tile_meter, un filino più arcaico del laser:-) , ma economico e divertente. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Traduzioni
Sono disponibile a contribuire anch'io alla traduzione. L'altra volta c'era un GDoc: come funziona questa volta ? Fabrizio Il giorno 29 marzo 2013 21:56, Leonardo kinetocor...@gmail.com ha scritto: Ciao, mi accodo anch'io per learnosm come traduttore :) Leonardo Il 29/03/2013 21:22, Giuliano ha scritto: Il 29/03/2013 20:08, sabas88 ha scritto: Ciao, chiedo nuovamente se c'è qualcuno che vuole aiutare nella traduzione dei due progetti attualmente più visibili in OSM, nel senso che saranno probabilmente il punto di ingresso dei nuovi utenti. Di iD, il nuovo editor, ho già scritto e ricevuto suggerimenti (grazie :-) ), però se qualcuno ha voglia di iscriversi a Transifex, può anche revisionare le stringhe già tradotte. https://www.transifex.com/**projects/p/id-editor/https://www.transifex.com/projects/p/id-editor/ Also, c'è la nuova versione di LearnOSM che necessita di traduzioni http://learnosm.org/it/ Ciao, Stefano Come si usa qui da noi? Si deve prenotare la traduzione? Oppure ognuno può decidere per proprio conto? Il testo risultante dove deve essere pubblicato? In linea di massima sarei disponibile a dare il mio contributo. Attendo qualche dritta. -- Giuliano __**_ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-ithttp://lists.openstreetmap.org/listinfo/talk-it __**_ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-ithttp://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Fwd: [OSM-talk] OSM Monster
scusate il cross-posting, ma è troppo bello ;-) ciao, Martin -- Forwarded message -- From: Martijn van Exel m...@rtijn.org Date: 2013/3/30 Subject: [OSM-talk] OSM Monster To: OSM Talk t...@openstreetmap.org OSM data turned into a monster! http://vimeo.com/62468031 -- Martijn van Exel __**_ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talkhttp://lists.openstreetmap.org/listinfo/talk ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Fwd: [OSM-talk] OSM Monster
Molto bello! Peccato che abbia scelto uno stile di mappa che ricorda molto GMaps... :-) Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-co] Nombres de ríos en Colombia
2013/3/29 Igor TAmara i...@tamarapatino.org Humberto, muchas gracias por la información, no se si conozcan algún sitio que indique cuáles son por ejemplo los límites municipales, he visto que varios municipios que he visitado justamente están delimitados por un río o una quebrada, entonces a partir de ello podría deducirla, busqué en las páginas de las alcaldías, pero posiblemente no lo hice bien, también en la wikipedia y llegué a un servicio que ofrece la CAR que muestra referencias a documentos impresos. El agua del país y los estudios de investigación y de campo deberían ser de licencia abierta y estar disponibles para uso de todos puesto que ese dinero ya se pagó, necesitamos que en los presupuestos haya dinero para la creación de los sistemas y el mantenimiento de los mismos que nos permitan como colombianos identificar y velar por este recurso vital. En el Cauca existe algo que se llama CIAGUA http://www.ciagua.org y aunque el sitio parece no estar actualizado creo que siguen trabajando en proyectos alrededor de este tema. Saludos. Eventualmente comenzar a darle relevancia y visibilidad a este recurso puede hacer que despertemos más conciencias en la necesidad de embarcarnos en proyectos para el futuro de todos y no solamente la actitud minera que está tan de moda en este momento :( El 29 de marzo de 2013 20:14, Igor TAmara i...@tamarapatino.orgescribió: Hola Nicolás, chévere, no se cuál sea la mejor forma de compartirla, eventualmente la montaríamos sobre el Geonode? con eso podemos a partir del WMS usar QGIS. El 29 de marzo de 2013 08:43, Nicolás Vargas Ramírez vargasramireznico...@gmail.com escribió: Hola compas En el SIGOT pueden descargarse los shapefiles de hidrología de todo Colombia a escala 1:100.000 y puede servir para guiarse. Tambien tengo escaneadas muchas planchas del IGAC 1:25.000 que igualmente pueden servir, aunque por lo general hay bastantes errores en las toponimias. Las planchas las tengo georeferenciadas en Magna Bogotá, pero las puedo pasar a la proyección con que trabaja OSM sin problema. Es WGS84, verdad? Con gusto puedo compartir esa información si consideran que es útil para los fines de OSM, teniendo en cuenta que esta info sólo puede usarse de referencia para etiquetar por aquello del copyright. Me cuentan porfa Nico Vargas El 28/03/2013, a las 10:27 p.m., hyan...@gmail.com hyan...@gmail.com escribió: El 28 de marzo de 2013 15:45, Igor TAmara i...@tamarapatino.orgescribió: Hola, el agua como recurso natural es de lo más valioso en nuestro país, y cada vez que vamos por vías tratamos de colocar nombres a ríos y afluentes, hay bastantes sin nombrar, saben de algún sitio donde se pueda hacer la consulta de nombres de ríos para etiquetar los que vamos mapeando? En particular con la aerofotografía es bueno colocar esos cauces, pero aún mejor si colocamos los nombres :) ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co Hola Igor: Este artículo de Wikipedia tiene una gráfica con nombres de los principales ríos: http://es.wikipedia.org/wiki/Hidrograf%C3%ADa_de_Colombia A todos los que deseen mapear la hidrología del país: - Las imágenes Landsat (cubriendo todo el territorio colombiano) permiten calcar la mayoría de los ríos, riachuelos y cuerpos de agua (donde no hay nubosidad), las pueden llamar por su nombre desde el menú Imágenes en el JOSM o estas aparecen en las áreas de Bing sin cobertura de imágenes de alta resolución; - El plugin Fastdraw [1] de JOSM facilita y acelera el calcado de estos elementos geográficos: se llama con Shift+F, genera nodos automáticos oprimiendo la barra espaciadora, entonces moviendo el ratón aparecerá los trazos en borrador, al terminar para confirmar un enter, luego la flecha hacia arriba si desea incrementar el número de nodos para una mejor definición y para terminar un segundo enter; - Se mapea como río (waterway=river) [2] aquellos que tengan más de 12m de ancho, si es inferior a eso se usa 'waterway=stream'. La escala en la parte superior izquierda del JOSM ayuda a definir el ancho del río. Cuando no se ve la otra orilla del río se mapea el área del río con polígono y 'waterway=riverbank'; - La etiqueta 'waterway=canal, ditch o drain' se usa solo para cursos de aguas hechos por el hombre. Feliz hidromapeo! Humberto Yances [1] http://wiki.openstreetmap.org/wiki/JOSM/Plugins/FastDraw [2] http://wiki.openstreetmap.org/wiki/Map_Features#Waterway ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co --
Re: [Talk-co] Nombres de ríos en Colombia
Hola Igor: He transformado los (+80.000) puntos de GEOnet (dominio público) a GPX, están para descarga en: http://dl.dropbox.com/u/1720266/GEOnet-co1.gpx http://dl.dropbox.com/u/1720266/GEOnet-co2.gpx Los he abierto con el JOSM y colocado sobre la capa de imágenes Bing con colores vistosos (rojo, amarillo y azul) (click derecho sobre el nombre de la capa para cambiar color). Se ve bien e identifica la quebrada, río, ciénaga, laguna, población, etc. que se esté mapeando. Luego analizamos la vía de subir los GPX a OSM como trazas. Sobre lo que propones secundo la línea de Edwin Caldon, en primera instancia ofreciendo a instituciones tales como CIAGUA el uso de la data de OSM para sus proyectos de monitoreo y alertas tempranas. Saludos, Humberto Yances El 29 de marzo de 2013 20:18, Igor TAmara i...@tamarapatino.org escribió: Humberto, muchas gracias por la información, no se si conozcan algún sitio que indique cuáles son por ejemplo los límites municipales, he visto que varios municipios que he visitado justamente están delimitados por un río o una quebrada, entonces a partir de ello podría deducirla, busqué en las páginas de las alcaldías, pero posiblemente no lo hice bien, también en la wikipedia y llegué a un servicio que ofrece la CAR que muestra referencias a documentos impresos. El agua del país y los estudios de investigación y de campo deberían ser de licencia abierta y estar disponibles para uso de todos puesto que ese dinero ya se pagó, necesitamos que en los presupuestos haya dinero para la creación de los sistemas y el mantenimiento de los mismos que nos permitan como colombianos identificar y velar por este recurso vital. Eventualmente comenzar a darle relevancia y visibilidad a este recurso puede hacer que despertemos más conciencias en la necesidad de embarcarnos en proyectos para el futuro de todos y no solamente la actitud minera que está tan de moda en este momento :( El 29 de marzo de 2013 20:14, Igor TAmara i...@tamarapatino.orgescribió: Hola Nicolás, chévere, no se cuál sea la mejor forma de compartirla, eventualmente la montaríamos sobre el Geonode? con eso podemos a partir del WMS usar QGIS. El 29 de marzo de 2013 08:43, Nicolás Vargas Ramírez vargasramireznico...@gmail.com escribió: Hola compas En el SIGOT pueden descargarse los shapefiles de hidrología de todo Colombia a escala 1:100.000 y puede servir para guiarse. Tambien tengo escaneadas muchas planchas del IGAC 1:25.000 que igualmente pueden servir, aunque por lo general hay bastantes errores en las toponimias. Las planchas las tengo georeferenciadas en Magna Bogotá, pero las puedo pasar a la proyección con que trabaja OSM sin problema. Es WGS84, verdad? Con gusto puedo compartir esa información si consideran que es útil para los fines de OSM, teniendo en cuenta que esta info sólo puede usarse de referencia para etiquetar por aquello del copyright. Me cuentan porfa Nico Vargas El 28/03/2013, a las 10:27 p.m., hyan...@gmail.com hyan...@gmail.com escribió: El 28 de marzo de 2013 15:45, Igor TAmara i...@tamarapatino.orgescribió: Hola, el agua como recurso natural es de lo más valioso en nuestro país, y cada vez que vamos por vías tratamos de colocar nombres a ríos y afluentes, hay bastantes sin nombrar, saben de algún sitio donde se pueda hacer la consulta de nombres de ríos para etiquetar los que vamos mapeando? En particular con la aerofotografía es bueno colocar esos cauces, pero aún mejor si colocamos los nombres :) ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co Hola Igor: Este artículo de Wikipedia tiene una gráfica con nombres de los principales ríos: http://es.wikipedia.org/wiki/Hidrograf%C3%ADa_de_Colombia A todos los que deseen mapear la hidrología del país: - Las imágenes Landsat (cubriendo todo el territorio colombiano) permiten calcar la mayoría de los ríos, riachuelos y cuerpos de agua (donde no hay nubosidad), las pueden llamar por su nombre desde el menú Imágenes en el JOSM o estas aparecen en las áreas de Bing sin cobertura de imágenes de alta resolución; - El plugin Fastdraw [1] de JOSM facilita y acelera el calcado de estos elementos geográficos: se llama con Shift+F, genera nodos automáticos oprimiendo la barra espaciadora, entonces moviendo el ratón aparecerá los trazos en borrador, al terminar para confirmar un enter, luego la flecha hacia arriba si desea incrementar el número de nodos para una mejor definición y para terminar un segundo enter; - Se mapea como río (waterway=river) [2] aquellos que tengan más de 12m de ancho, si es inferior a eso se usa 'waterway=stream'. La escala en la parte superior izquierda del JOSM ayuda a definir el ancho del río. Cuando no se ve la otra orilla del río se mapea el área del río con polígono y 'waterway=riverbank'; - La
Re: [Talk-co] Nombres de ríos en Colombia
Hola Nicolás: OSM usa como sistema de coordenadas el WSG84, el sistema de proyección de coordenadas es Google Mercator. Todo esto y más en: https://github.com/hotosm/learnosm/wiki/English-Learning-Guides El capítulo sobre sistemas de coordenadas es este: https://docs.google.com/document/d/1o1SnIvkHpWbcLTH5PTKQ2vziTJlIGQB7iVe2K04cBYA/edit Hago recorderis que hay convocatoria para edición del Learn OSM [1] al español: https://github.com/hotosm/learnosm/issues/63 Saludos, [1] http://learnosm.org/en/ PD: Sería bueno conocer sobre los términos de la licencia de las fuentes que propones, es imprescindible conocer su compatibilidad con OSM antes de su uso. http://wiki.openstreetmap.org/wiki/Legal_FAQ#2b._XYZ_Organisation_has_data_for_free_download_under_licence_N._Can_I_use_it_in_OSM.3F El 29 de marzo de 2013 08:43, Nicolás Vargas Ramírez vargasramireznico...@gmail.com escribió: Hola compas En el SIGOT pueden descargarse los shapefiles de hidrología de todo Colombia a escala 1:100.000 y puede servir para guiarse. Tambien tengo escaneadas muchas planchas del IGAC 1:25.000 que igualmente pueden servir, aunque por lo general hay bastantes errores en las toponimias. Las planchas las tengo georeferenciadas en Magna Bogotá, pero las puedo pasar a la proyección con que trabaja OSM sin problema. Es WGS84, verdad? Con gusto puedo compartir esa información si consideran que es útil para los fines de OSM, teniendo en cuenta que esta info sólo puede usarse de referencia para etiquetar por aquello del copyright. Me cuentan porfa Nico Vargas El 28/03/2013, a las 10:27 p.m., hyan...@gmail.com hyan...@gmail.com escribió: El 28 de marzo de 2013 15:45, Igor TAmara i...@tamarapatino.orgescribió: Hola, el agua como recurso natural es de lo más valioso en nuestro país, y cada vez que vamos por vías tratamos de colocar nombres a ríos y afluentes, hay bastantes sin nombrar, saben de algún sitio donde se pueda hacer la consulta de nombres de ríos para etiquetar los que vamos mapeando? En particular con la aerofotografía es bueno colocar esos cauces, pero aún mejor si colocamos los nombres :) ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co Hola Igor: Este artículo de Wikipedia tiene una gráfica con nombres de los principales ríos: http://es.wikipedia.org/wiki/Hidrograf%C3%ADa_de_Colombia A todos los que deseen mapear la hidrología del país: - Las imágenes Landsat (cubriendo todo el territorio colombiano) permiten calcar la mayoría de los ríos, riachuelos y cuerpos de agua (donde no hay nubosidad), las pueden llamar por su nombre desde el menú Imágenes en el JOSM o estas aparecen en las áreas de Bing sin cobertura de imágenes de alta resolución; - El plugin Fastdraw [1] de JOSM facilita y acelera el calcado de estos elementos geográficos: se llama con Shift+F, genera nodos automáticos oprimiendo la barra espaciadora, entonces moviendo el ratón aparecerá los trazos en borrador, al terminar para confirmar un enter, luego la flecha hacia arriba si desea incrementar el número de nodos para una mejor definición y para terminar un segundo enter; - Se mapea como río (waterway=river) [2] aquellos que tengan más de 12m de ancho, si es inferior a eso se usa 'waterway=stream'. La escala en la parte superior izquierda del JOSM ayuda a definir el ancho del río. Cuando no se ve la otra orilla del río se mapea el área del río con polígono y 'waterway=riverbank'; - La etiqueta 'waterway=canal, ditch o drain' se usa solo para cursos de aguas hechos por el hombre. Feliz hidromapeo! Humberto Yances [1] http://wiki.openstreetmap.org/wiki/JOSM/Plugins/FastDraw [2] http://wiki.openstreetmap.org/wiki/Map_Features#Waterway ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
[Talk-dk] Fejlplacerede punkter på cyklistic.dk
Hej, Det er måske ikke det rigtige sted at gøre opmærksom på dette, men nålene på cyclistic.dk's kort er fejlplacerede. Tilsyneladende er de centrerede på punktet, hvor nålespidsen skulle være. Jeg har selv mappet Ballen Havn som ses på vedlagte skærmskud fra cyclistic.dk, og jeg ved positivt at hverken toiletter eller picnicborde er ude i vandet ;) Værd at overveje når man laver applikationer med kort! En anden tanke jeg får ved at se på cyclistic.dk er hvor vigtigt det er at få access tags med når man mapper. Jeg ved i alt fald fra min lokale havnefoged (ikke i Ballen) at havnenes toiletter og andre faciliteter egentlig ikke bør betragtes som offentlige, men som en service for havnens betalende brugere og gæster. Selv om folk sjældent bliver bedt om at forføje sig, kan jeg forestille mig at man ikke alle steder ønsker sig at faciliteterne annonceres på cyclistic.dk. Venlig hilsen, Anders Lundattachment: horror1.jpeg___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Fejlplacerede punkter på cyklistic.dk
Hm, et problem til - som viser OSMs overlegenhed ;) Som det ses af vedlagte skærmskud, viser cyclistic.dk drejø gammelhavn to gange, ingen af dem der hvor havnen faktisk er. Disse fejlbehæftede data kommer tilsyneladende fra visitdenmark. Samme problem kan ses hvis man bevæger sig lidt mod nordøst til Skarø - og sikkert masser af andre steder Brug istedet OSMs data - havnene findes også der, og korrekt placeret med marina eller harbour tags ;) Lørdag den 30. marts 2013 12:23:15 skrev Anders Lund: Hej, Det er måske ikke det rigtige sted at gøre opmærksom på dette, men nålene på cyclistic.dk's kort er fejlplacerede. Tilsyneladende er de centrerede på punktet, hvor nålespidsen skulle være. Jeg har selv mappet Ballen Havn som ses på vedlagte skærmskud fra cyclistic.dk, og jeg ved positivt at hverken toiletter eller picnicborde er ude i vandet ;) Værd at overveje når man laver applikationer med kort! En anden tanke jeg får ved at se på cyclistic.dk er hvor vigtigt det er at få access tags med når man mapper. Jeg ved i alt fald fra min lokale havnefoged (ikke i Ballen) at havnenes toiletter og andre faciliteter egentlig ikke bør betragtes som offentlige, men som en service for havnens betalende brugere og gæster. Selv om folk sjældent bliver bedt om at forføje sig, kan jeg forestille mig at man ikke alle steder ønsker sig at faciliteterne annonceres på cyclistic.dk. Venlig hilsen, Anders Lundattachment: image/png___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-gb-westmidlands] Easter Weekend
Gregory (or anyone else interested),
(This mail was bounced earlier today because I use the wrong email address)
We're planning to get some curry tonight and otherwise we're having drinks
on Sunday evening.
Mark Iliffe might be joining us on Sunday.
Let us know if you will join!
Greets Floris
On Thursday, March 28, 2013, Gregory wrote:
Hmm, a shame it's short notice and the one weekend I'm busy travelling.
I'm partially thinking I could be in Brum for Saturday evening, it would
be good to meet the folk I don't know.
Durham to Nottingham via Birmingham is a strange route, but the detour
makes it cheaper if I hitch a lift from Birmingham way with my brother.
Greg.
On 27 March 2013 17:20, Brian Prangle bpran...@gmail.comjavascript:_e({},
'cvml', 'bpran...@gmail.com');
wrote:
Hi everyone
Henk and Floris are coming over from the Netherlands this weekend to do
some scouting and videoing for the conference. They've suggested a
pub/curry get together for either Sat or Sun evening. Anyone around?
Anyone want to meet Henk and Floris?
Regards
Brian
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org javascript:_e({}, 'cvml',
'Talk-gb-westmidlands@openstreetmap.org');
http://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
--
Gregory
o...@livingwithdragons.com javascript:_e({}, 'cvml',
'o...@livingwithdragons.com');
http://www.livingwithdragons.com
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
Re: [Talk-gb-westmidlands] Easter Weekend
Is probably too late for me to get over there now :-( What time and where? Also let me know the plans for Sunday Rob On 30 March 2013 18:07, Floris Looijesteijn o...@floris.nu wrote: Gregory (or anyone else interested), (This mail was bounced earlier today because I use the wrong email address) We're planning to get some curry tonight and otherwise we're having drinks on Sunday evening. Mark Iliffe might be joining us on Sunday. Let us know if you will join! Greets Floris On Thursday, March 28, 2013, Gregory wrote: Hmm, a shame it's short notice and the one weekend I'm busy travelling. I'm partially thinking I could be in Brum for Saturday evening, it would be good to meet the folk I don't know. Durham to Nottingham via Birmingham is a strange route, but the detour makes it cheaper if I hitch a lift from Birmingham way with my brother. Greg. On 27 March 2013 17:20, Brian Prangle bpran...@gmail.com wrote: Hi everyone Henk and Floris are coming over from the Netherlands this weekend to do some scouting and videoing for the conference. They've suggested a pub/curry get together for either Sat or Sun evening. Anyone around? Anyone want to meet Henk and Floris? Regards Brian ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb-westmidlands -- Gregory o...@livingwithdragons.com http://www.livingwithdragons.com ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb-westmidlands ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
Re: [Talk-gb-westmidlands] Easter Weekend
Sunday It'll be a pub around 18:00. I'll let you know which one or give me
a call (+31624228803) if you want to find us.
On Saturday, March 30, 2013, Rob Nickerson wrote:
Is probably too late for me to get over there now :-( What time and where?
Also let me know the plans for Sunday
Rob
On 30 March 2013 18:07, Floris Looijesteijn o...@floris.nujavascript:_e({},
'cvml', 'o...@floris.nu');
wrote:
Gregory (or anyone else interested),
(This mail was bounced earlier today because I use the wrong email
address)
We're planning to get some curry tonight and otherwise we're having
drinks on Sunday evening.
Mark Iliffe might be joining us on Sunday.
Let us know if you will join!
Greets Floris
On Thursday, March 28, 2013, Gregory wrote:
Hmm, a shame it's short notice and the one weekend I'm busy travelling.
I'm partially thinking I could be in Brum for Saturday evening, it would
be good to meet the folk I don't know.
Durham to Nottingham via Birmingham is a strange route, but the detour
makes it cheaper if I hitch a lift from Birmingham way with my brother.
Greg.
On 27 March 2013 17:20, Brian Prangle bpran...@gmail.com wrote:
Hi everyone
Henk and Floris are coming over from the Netherlands this weekend to do
some scouting and videoing for the conference. They've suggested a
pub/curry get together for either Sat or Sun evening. Anyone around?
Anyone want to meet Henk and Floris?
Regards
Brian
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
--
Gregory
o...@livingwithdragons.com
http://www.livingwithdragons.com
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org javascript:_e({}, 'cvml',
'Talk-gb-westmidlands@openstreetmap.org');
http://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
Re: [Talk-ar] Imágen en el foro
El 29/03/13 00:09, Fabian Alejandro escribió: subila a www.imageshack.us http://www.imageshack.us o a facebook Traten de usar algo diferente a imageshack o por lo menos ver de que no expiren. Sino, dentro de un mes ves el mensaje del foro y ya no están las imágenes. -- Fernando Toledo Dock Sud BBS http://bbs.docksud.com.ar telnet://bbs.docksud.com.ar ___ Talk-ar mailing list Talk-ar@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ar
Re: [Talk-ee] Huvitavad tööriistad Eesti jaoks
Aerofoto on nüüd ka olemas. http://osm.svimik.com/btrace_verify.php Среда, 27 марта 2013, 9:54 +02:00 от Jaak Laineste (Nutiteq) j...@nutiteq.com: On 26.03.2013, at 22:37, SviMik wrote: Import building: praegu ma teen import Maa-ametist. On vaja ainult üle vaadata ja nuppu vajutada. http://osm.svimik.com/btrace_verify.php Vau, see on küll vägev vidin ! Teisi ei ole veel vaadanud. Kiire idee: ma eelistaksin taustakaardina aerofotot (Maa-ametil on 2012 fotod just välja pandud), näiteks OSM preview tausta valikuna. See annaks palju enam uuemat infot kas see maja on tõesti seal olemas, või vahepeal lammutatud näiteks. Jaak ___ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee
Re: [Talk-ee] Huvitavad tööriistad Eesti jaoks
Loodan et sain aru õigesti: Nüüd Missing streets leheküljel on kaks lingid: small bbox ja full bbox. http://osm.svimik.com/nostreet.php full bbox tells JOSM to download and select all buildings with given street name. Вторник, 26 марта 2013, 23:20 +02:00 от Margus Värton mar...@dakar.ee: Vägevad tööriistad, respect. Aga puudust tunnen võimalusest määrata bounding box alale, kus tegutsen - et saaks hakatuseks mulle tuttavamad kohad paika nokkida. - M - ___ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee
Re: [Talk-at] OpenData, Wiener Linien halten Daten zurück
Auch auf data.wien.gv.at ist es zu lesen: http://data.wien.gv.at/neuigkeiten/wiener-linien.html lg jimmy Am 29.03.2013 10:50, schrieb Andreas Labres: Wiener Linien zwitschern: Open Data? Wir haben verstanden. Verkehrsdaten der Wiener Linien bis Sommer freigegeben. Mehr dazu auf... http://blog.wienerlinien.at/open-data-wir-haben-verstanden/ /al ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] Abus des landuse=residential ?
Salut Le vendredi 29 mars 2013 à 15:51 +0100, kimaidou a écrit : Bonjour, En me balladant du côté de St Gély du Fesc, j'ai constaté une utilisation très intensive de polygones hyghway=residential http://www.openstreetmap.org/?lat=43.69214lon=3.80766zoom=15layers=M J'ai regardé. En discutant avec des randonneurs le week-end dernier, il peut être intéressant de représenter les limites de parcelles « en campagne ». Notamment pour les lignes d'arbres, les haies, les ruisseaux, tout ce qui visuellement peut renseigner le randonneur sur le terrain. Ainsi, il se repère mieux dans l'environnement où il se trouve. En lotissement, représenter des parcelles collées les unes aux autres, les cabanes en fond de jardin et les piscines privées n'apportent aucune plus value. L'intérêt est moindre voire inexistant dans ce cas précis. Par contre, les chemins entre parcelles, les poi incendie, croix, bornes, parking, etc... là oui, ce sont de bons repères. Évidemment, tout dépend l'usage qu'on fait des données collectées. À mon avis, ce n'est pas parce que l'on a des informations par satellite ou cadastre qu'il faut nécessairement les reporter. Je suis assez partisan du respect de la vie privée d'une part et de l'utilité pour la communauté de l'autre. Je ne souhaite pas qu'OSM tombe dans le voyeurisme. Pour en revenir à St Gély du Fesc À l'extrémité de la rue des cades pour rejoindre le chemin existant, il manque un chemin (là où est le pointeur). Le trait est tracé (dans josm) mais il n'y a pas le tag highway (path ou footway). Je laisse un mappeur du coin corriger le problème. http://www.openstreetmap.org/?mlat=43.694212mlon=3.810982zoom=18layers=M a+ nono -- Le monstre du Loch Ness aurait déjà vu Chuck Norris. signature.asc Description: This is a digitally signed message part ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Smartphone low cost à conseiller pour cartographier ?
J'ai acheté un Wiko Cink Slim* pour tester (et aussi pour essayer les applis Android pour OSM). Premier constat: il reste effectivement peu de stockage libre (1,5Go), surtout si on charge un peu la bestiole avec des cartes pour OsmAnd. Donc besoin d'ajouter une microSD... 10 euros pour 8Go, 40 euros pour 32Go (le maximum pour ce smartphone, c'est ce que j'ai mis). Je l'ai utilisé sans carte SIM, donc connecté par wifi (soit à ma box, soit en partage 3G via mon iPhone). Il est rapide et agréable à utiliser, le GPS met du temps à se caler (normal, sans carte SIM, pas de A-GPS), mais une fois calé il a une précision tout à fait classique et comparable avec la majorité des GPS. Pour les photos, ça va très bien aussi, même si le déclenchement uniquement via une touche sur l'écran est quand même moins pratique que via le bouton de volume de l'iPhone. Capteur assez sensible et rapide, donc des photos nettes même avec une mauvaise lumière et il gère plutôt bien les contre jour quand on règle sa mesure d'exposition en centrale (chose que je ne peux pas faire sur mon iPhone). Côté abonnement 3G, je vais tester le forfait Idol à 9,99€/mois de Virgin Mobile (3G illimitée avec 1Go de fair use + 1h d'appels et le tout sans engagement) et voir ce que donne le A-GPS. Bref, pour 150 euros en comptant la microSD, ça tient la comparaison avec mon iPhone 4 et ça me semble un très bon outil pour les relevés sur le terrain. * en blanc... comme ça l'autocollant OSM semble d'origine ;) -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013 ynthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Smartphone low cost à conseiller pour cartographier ?
Pour 30€ de plus, le Wiko Cink Peax, dernier né de la gamme, en offre plus : - écran plus grand (45) - résolution plus fine (qHD) - double de RAM : 1Go (un gros plus pour Android 4.0 et supérieur) - batterie un peu plus grande - un peu plus léger Pourquoi s'en priver à ce prix-là ? @+ Le 30/03/13 10:39, Christian Quest a écrit : J'ai acheté un Wiko Cink Slim* pour tester (et aussi pour essayer les applis Android pour OSM). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Licence IP et ODBL ( était : L'ON3V libère ses donnés?)
Bonjour, On 29/03/2013 21:13, Vincent de Chateau-Thierry wrote: Bonsoir, Le 29/03/2013 19:54, sly (sylvain letuffe) a écrit : On vendredi 29 mars 2013, Romain MEHUT wrote: Par contre quelqu'un d'autre a indiqué que la licence IP serait incompatible avec l'Open Data étant donné la clause de non altération. Est-ce vraiment un élément qui rend incompatible ces données pour une réutilisation dans OSM? Et j'emmétrais moi même un fort doute. En effet, si la licence IP oblige une non altération des données, cela n'en fait plus une licence libre, et donc, elle n'est plus compatible avec ODBL. C'est la conclusion que nous avions eu à l'époque de sa sortie. De plus, il ne faut pas confondre la licence de l'APIE avec celle du ministère de la justice (bravo l'APIE) voir : http://www.regardscitoyens.org/licences-opendata-lapie-grille-la-priorite-a-etalab-et-invente-le-pseudo-libre/ Tout cela est bien dommage car il semble que DRC soit de très bonne volonté. Désolé pour un 1er message sur cette liste d'apporter des mauvaises nouvelles. Brice @bjperson Mais l'interprétation du texte de la licence peut être sujette à plusieurs manière de la lire (elle est pas clair pour moi en tout cas) L'article wikipedia indique que c'est une licence libre, mais aucune citation (à part un article de presse dont l'auteur me semble avoir confondue licence du texte de la licence et licence elle même), ce que je me suis permis de compléter/corriger/mettre en doute sur WP Sur le wiki Openstreetmap VDB semble avoir conclu que c'était bon : http://wiki.openstreetmap.org/wiki/WikiProject_France/G%C3%A9oLittoral Mais la licence IP oblige une étape d'enrichissement des données pour pouvoir relicencier le travail dérivé sous une autre licence (et en l'occurrence, c'est ce travail qui nous permet de faire le passage IP - CC BY-SA / ODbL à terme) Sauf que si je lis la licence : http://www.rip.justice.fr/information_publique_librement_reutilisable La présente licence précise les conditions juridiques de réutilisation des informations publiques conformément à l’article 12 de la loi n°78-753 du 17 juillet 1978 qui impose que les données ne soient pas altérées, que leur sens ne soit pas dénaturé et que leurs sources et leur date de mise à jour soient mentionnées. J'en arrive pas tout à fait à la même interprétation que lui. Mais cette IP ressemble un peu à celle du cadastre, c'est à dire qu'elle semble avoir pour but d'éviter que quelqu'un prenne, modifie et prétende que les nouvelles données sont la responsabilité de l'organisme qui les a libérées. Genre : modifier si vous voulez, mais dites bien que c'est une version dérivée de chez nous, pas la notre Mais ça mériterait quand même un bon éclaircissement, de ce que je lis, dans une posture de prudence, c'est non, on peut pas Sur la page de téléchargement je lis : Les données peuvent faire l’objet de traitements, notamment lorsqu’ils sont nécessaires à la réalisation d’une nouvelle application ou d’un nouveau produit ou service. On entend notamment par traitement, le regroupement d’informations, le renseignement de métadonnées, l‘enrichissement, les modifications nécessaires pour permettre l’interopérabilité des données avec d’autres données. Ça ouvre quand même l'usage, en permettant d'envisager dès le départ que la donnée va être modifiée, par les traitements. Modification et altération sont deux choses bien distinctes, la première n'implique pas qu'on va dégrader la source. Concrètement si on envisage une intégration dans OSM, en rapprochant les tracés fournis des tracés highway=* existant dans notre base, que va-t-on faire ? - découper ou agréger l'information pour la faire correspondre à la granularité des données OSM, - déplacer l'information pour l'associer à des objets +/- distants, si le calage ou la précision géométrique de la source sont moindres que les tracés OSM correspondants. Rien que par ces deux exemples, on rentre dans le cadre prévu par la licence : on regroupe, on enrichit (en combinant les infos à celles des highway=* par ex.), on modifie (au moins la géométrie), pour autant on ne dénature ni n'altère les données, et au final on les rend interopérables avec le reste des données OSM. ...mais je ne suis pas juriste. vincent (qui voit le verre à moitié plein) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Conférence OSM le 10 avril à Orléans
Salut Je verrai si je peux venir. J'ai des gilets supplémentaires à apporter. Émilie laffray On 30 Mar 2013 10:26, Etienne Trimaille etienne.trimai...@gmail.com wrote: Une présentation d'OSM aura lieu le mercredi 10 avril de 20h30 à 23h00 à la Maison des Associations. http://www.openstreetmap.org/?mlat=47.90166mlon=1.905425zoom=18layers=M http://wiki.cenabumix.org/images/ConfOSM800.jpg ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Piste VTT (les 2 Alpes)
Je tombe par hasard sur des pistes VTT aux 2 Alpes, comme par ex : http://www.openstreetmap.org/browse/way/67502440 A l'époque, j'aurais plutôt mis un highway=track avec une relation de type route=mtb. Vue la faible largeur de la piste, track ne me paraît pas adapté (on ne peut passer en 4x4). Alors, correct? Pas correct? Moi, ça me va tout à fait. Il y a peut-être une légère redondance entre mtb:type = downhill et oneway = yes Le seul qui ne va pas, c'est de couper comme ça les virages ;-) Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] export d'extraits
En décembre, on parlait d'exports d'extraits de la base, à la manière de géofabrik, mais avec la possibilité de définir sa zone (http://www.mail-archive.com/talk-fr@openstreetmap.org/msg51934.html). Certains avaient l'air bien partants. Cette idée a-t-elle été abandonnée en route, ou s'est-elle simplement endormie en chemin ? Je lorgnais avec impatience sur cette possibilité de faire des extracts de taille moyenne… JB. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Smartphone low cost à conseiller pour cartographier ?
Disons que pour 150 à 200€ ces smartphones premier prix sont tout à fait corrects pour faire des relevés sur le terrain et que je les conseillerai sans problème à quelqu'un qui veut s'équiper pour mapper. Ensuite, en fonction des autres usages qu'on peut en faire, on peut préférer tel ou tel modèle, mais même le tout premier prix de la gamme est suffisant. Côté autonomie, ça n'a pas l'air trop mauvais, je suis en train de faire encore quelques cycles de charge/décharge pour condition au mieux la batterie, mais sur mon premier essai, j'ai tenu plusieurs heures avec le GPS allumé. Je le testerai plus à fond à Brocas le week-end prochain et au pire j'ai ma batterie complémentaire. Le 30 mars 2013 12:09, Lapinos03 lapino...@free.fr a écrit : Pour 30€ de plus, le Wiko Cink Peax, dernier né de la gamme, en offre plus : - écran plus grand (45) - résolution plus fine (qHD) - double de RAM : 1Go (un gros plus pour Android 4.0 et supérieur) - batterie un peu plus grande - un peu plus léger Pourquoi s'en priver à ce prix-là ? @+ Le 30/03/13 10:39, Christian Quest a écrit : J'ai acheté un Wiko Cink Slim* pour tester (et aussi pour essayer les applis Android pour OSM). __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013ynthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] export d'extraits
Le samedi 30 mars 2013 15:37:41, JB a écrit : En décembre, on parlait d'exports d'extraits de la base, à la manière de géofabrik, mais avec la possibilité de définir sa zone (http://www.mail-archive.com/talk-fr@openstreetmap.org/msg51934.html). Certains avaient l'air bien partants. Ce lien vers un de mes messages faisait référence à osm2gis qui est opérationnel ici : http://www.osm974.re/osm2gis/ Sauf erreur, il utilise désormais bien la base osm2pgsql monde des serveurs de l'association osm-f Arnaud, son auteur, pourra sûrement en dire plus. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Abus des landuse=residential ?
Le sam. 30 mars 2013 à 07:52 +0100, nono a écrit : J'ai regardé. En discutant avec des randonneurs le week-end dernier, il peut être intéressant de représenter les limites de parcelles « en campagne ». Notamment pour les lignes d'arbres, les haies, les ruisseaux, tout ce qui visuellement peut renseigner le randonneur sur le terrain. Ainsi, il se repère mieux dans l'environnement où il se trouve. Tout à fait, mais dans ce cas, il ne s'agit pas de tracer une limite de parcelle, mais un autre élément, naturel ou artificiel (barrier=hedge, waterway=stream|ditch...) qui peut éventuellement marquer une limite de parcelle. -- ° /\Guillaume AllègreOpenStreetMap France /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative / /~~\tél. 04.76.63.26.99 http://www.openstreetmap.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] expérimentations à Orange
Salut, Je voudrais signaler certains problèmes (du moins qui m'apparaissent tels) des expérimentations d'import dans OSM de données communales à Orange. Je sais que cela concerne le travail de Tony, tel qu'il l'a présenté au SOTM-FR, mais je pense qu'il vaut mieux avoir plusieurs avis. Prenez l'objet boundary=polling_station http://www.openstreetmap.org/browse/way/197278529 membre de la relation http://www.openstreetmap.org/browse/relation/2649371 Je vois plusieurs problèmes : 1) la boundary est une frontière de canton, qui coïncide avec un bout de la frontière communale (Orange / Caderousse) http://www.openstreetmap.org/?way=171243851 mais qui n'est pas confondue (points distincts) Selon moi, elle devrait être confondue, en tant que limite communale ET limite de canton. 2) le way polling_station a une résolution bien plus élevée (1 point par mètre dans les courbes), suivant les _anciens_ méandres de la Meyne, qui restent la limite communale comme ici : http://www.openstreetmap.org/?lat=44.08722lon=4.7789zoom=17layers=M A mon avis, c'est de la sur-résolution inutile, mais ça se discute. Cela n'enlève rien au point 1 : il faut choisir quelle limite on prend (171243851 ou 197278529), voire un intermédiaire en simplifiant la limite polling_station, mais il faut quand même à terme fusionner les deux. 3) La relation 2649371 a des attributs bizarres : - pas de nom - un CANTON=Ouest pas documenté - un ref=22 pas documenté non plus 4) la route http://www.openstreetmap.org/browse/way/195747326 a les attributs : highway = road addr:postcode = |84100 ref:orange = 84087V99 En dehors de la typo sur le code postal avec le |, est-ce logique de mettre un code postal sur une voie ? le wiki ne donne qu'un noeud ou une surface, et j'aurais tendance à le suivre sur ce point. Ensuite : ref:orange : là, je pense qu'on a un problème à régler. orange n'est pas suffisamment distinctif. Si toutes les communes du monde se mettent à utiliser le même schéma, on va multiplier les conflits. Comment régler ça ? Je ne remets pas en cause l'utilisation d'OSM comme support de données métiers issues de SIG territoriaux, bien au contraire. Mais si, comme je le suppose, Orange tend à devenir une zone d'exemple et de démonstration pour cette convergence, il serait préférable que le schéma suivi soit aussi irréprochable que possible quant à l'intégration dans les conventions standard OSM. Alors, je pense qu'il faut sérieusement se pencher sur : - le schéma d'attributs et de références qui conviendrait à tout le monde - les conventions de fusion ou juxtaposition de données, et les précisions géométriques minimales/maximales acceptables. Des avis ? -- ° /\Guillaume AllègreOpenStreetMap France /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative / /~~\tél. 04.76.63.26.99 http://www.openstreetmap.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Bonsoir, Le 30/03/2013 20:37, Guillaume Allegre a écrit : 1) la boundary est une frontière de canton, qui coïncide avec un bout de la frontière communale (Orange / Caderousse) http://www.openstreetmap.org/?way=171243851 mais qui n'est pas confondue (points distincts) Selon moi, elle devrait être confondue, en tant que limite communale ET limite de canton. oui, fusionner la portion commune 3) La relation 2649371 a des attributs bizarres : - pas de nom - un CANTON=Ouest pas documenté - un ref=22 pas documenté non plus S'agissant de l'extension géographique d'un bureau de vote, on peut concevoir qu'il n'ait pas de nom mais juste un n° (le tag ref). 4) la route http://www.openstreetmap.org/browse/way/195747326 a les attributs : highway = road addr:postcode = |84100 ref:orange = 84087V99 En dehors de la typo sur le code postal avec le |, est-ce logique de mettre un code postal sur une voie ? le wiki ne donne qu'un noeud ou une surface, et j'aurais tendance à le suivre sur ce point. Pas sûr que ce soit une typo, ça peut être la moitié d'une modélisation sur un seul champ (dans un SIG) : code_postal à gauche | code postal à droite Pas forcément heureux là où nous sommes plus habitués à des suffixes :left et :right, et donc à deux attributs au lieu d'un. Mais la modélisation directement sur les ways est banale, quasi conventionnelle, chez les fournisseurs de BD de géocodage (IGN, TomTom co). Elle n'est pas documentée dans OSM, soit. Ça ne la rend pas invalide pour autant, et rien qu'en France, dans les quelques communes a CP multiples, ça se conçoit. Ensuite : ref:orange : là, je pense qu'on a un problème à régler. orange n'est pas suffisamment distinctif. Si toutes les communes du monde se mettent à utiliser le même schéma, on va multiplier les conflits. Comment régler ça ? Pour éviter d'avoir 36.000 tags ref:* distincts à terme (on peut rêver), je verrais plutôt un schéma générique sur 2 tags : source=* (rien de nouveau ici) ref:source=* ou source:internal_id ou toute autre formulation pour dire la même chose : mentionner l'identifiant unique utilisé par le fournisseur. Dans l'exemple du way : source=Mairie d'Orange 2012 ref:source=84087V99 Après tout, il ne s'agit pas d'un tag ref pour l'objet, que tout un chacun pourrait trouver sur le terrain, mais d'un tag ref qui n'existe que parce qu'une certaine source a été utilisée pour l'objet. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 30 mars 2013 20:37, Guillaume Allegre allegre.guilla...@free.fr a écrit : 3) La relation 2649371 a des attributs bizarres : - pas de nom - un CANTON=Ouest pas documenté - un ref=22 pas documenté non plus En effet, on a un schéma déja existant et homogène utilisant le code Insee complet du canton à 4 chiffres dans ref:INSEE=*. avec boundary=political, political_division=canton, name=Orange-Ouest, wikipedia=fr:Canton d'Orange-Ouest 4) la route http://www.openstreetmap.org/browse/way/195747326 a les attributs : highway = road addr:postcode = |84100 ref:orange = 84087V99 En dehors de la typo sur le code postal avec le |, est-ce logique de mettre un code postal sur une voie ? le wiki ne donne qu'un noeud ou une surface, et j'aurais tendance à le suivre sur ce point. Ensuite : ref:orange : là, je pense qu'on a un problème à régler. orange n'est pas suffisamment distinctif. Si toutes les communes du monde se mettent à utiliser le même schéma, on va multiplier les conflits. Comment régler ça ? Pour les références relatives à Orange, ou semble-t-il plutôt son EPCI, il serait plus utile d'indiquer ref:FR:EPCI=* (avec une abréviation de l'EPCI) ou ref:FR:code insee de la commune=* (si cela vient de la commune elle-même). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le sam. 30 mars 2013 à 21:58 +0100, Philippe Verdy a écrit : Le 30 mars 2013 20:37, Guillaume Allegre allegre.guilla...@free.fr a écrit : 3) La relation 2649371 a des attributs bizarres : - pas de nom - un CANTON=Ouest pas documenté - un ref=22 pas documenté non plus En effet, on a un schéma déja existant et homogène utilisant le code Insee complet du canton à 4 chiffres dans ref:INSEE=*. avec boundary=political, political_division=canton, name=Orange-Ouest, wikipedia=fr:Canton d'Orange-Ouest Je reconnais que mon exemple était ambigu, mais la relation n'est pas un canton, mais la limite d'un bureau de vote (numéro 22), qui appartient au Canton Ouest. La question subsidiaire : vaut-il mieux avoir un nom Limite du bureau de vote n°22 (complètement redondant) ou rien ? 4) la route http://www.openstreetmap.org/browse/way/195747326 a les attributs : highway = road addr:postcode = |84100 ref:orange = 84087V99 En dehors de la typo sur le code postal avec le |, est-ce logique de mettre un code postal sur une voie ? le wiki ne donne qu'un noeud ou une surface, et j'aurais tendance à le suivre sur ce point. Ensuite : ref:orange : là, je pense qu'on a un problème à régler. orange n'est pas suffisamment distinctif. Si toutes les communes du monde se mettent à utiliser le même schéma, on va multiplier les conflits. Comment régler ça ? Pour les références relatives à Orange, ou semble-t-il plutôt son EPCI, il serait plus utile d'indiquer ref:FR:EPCI=* (avec une abréviation de l'EPCI) ou ref:FR:code insee de la commune=* (si cela vient de la commune elle-même). Non, c'est bien la commune seule. Orange ne fait à ma connaissance toujours partie d'aucune intercommunalité, principalement en raison du bord politique du maire (ex-FN) depuis 1995. Le ref:FR:code insee de la commune= * paraît rationnel, mais un peu aride. Cela dit, pour un ref, ça peut passer. -- ° /\Guillaume AllègreOpenStreetMap France /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative / /~~\tél. 04.76.63.26.99 http://www.openstreetmap.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le sam. 30 mars 2013 à 21:45 +0100, Vincent de Chateau-Thierry a écrit : 4) la route http://www.openstreetmap.org/browse/way/195747326 a les attributs : highway = road addr:postcode = |84100 ref:orange = 84087V99 En dehors de la typo sur le code postal avec le |, est-ce logique de mettre un code postal sur une voie ? le wiki ne donne qu'un noeud ou une surface, et j'aurais tendance à le suivre sur ce point. Pas sûr que ce soit une typo, ça peut être la moitié d'une modélisation sur un seul champ (dans un SIG) : code_postal à gauche | code postal à droite Pas forcément heureux là où nous sommes plus habitués à des suffixes :left et :right, et donc à deux attributs au lieu d'un. OK, merci, je n'y avais pas pensé. C'est vrai que le bout de route traverse la frontière Caderousse/Orange, qui est aussi une limite de code postal (84860/84100) mais elle ne la suit pas. Donc je ne sais pas si ton interprétation est la bonne. Mais la modélisation directement sur les ways est banale, quasi conventionnelle, chez les fournisseurs de BD de géocodage (IGN, TomTom co). Elle n'est pas documentée dans OSM, soit. Ça ne la rend pas invalide pour autant, et rien qu'en France, dans les quelques communes a CP multiples, ça se conçoit. OK ; ça fait sens. Mais dans ce cas, il faudrait que ce soit renseigné sur le wiki, avec les variantes :left et :right. Ensuite : ref:orange : là, je pense qu'on a un problème à régler. orange n'est pas suffisamment distinctif. Si toutes les communes du monde se mettent à utiliser le même schéma, on va multiplier les conflits. Comment régler ça ? Pour éviter d'avoir 36.000 tags ref:* distincts à terme (on peut rêver), je verrais plutôt un schéma générique sur 2 tags : source=* (rien de nouveau ici) ref:source=* ou source:internal_id ou toute autre formulation pour dire la même chose : mentionner l'identifiant unique utilisé par le fournisseur. Dans l'exemple du way : source=Mairie d'Orange 2012 ref:source=84087V99 Après tout, il ne s'agit pas d'un tag ref pour l'objet, que tout un chacun pourrait trouver sur le terrain, mais d'un tag ref qui n'existe que parce qu'une certaine source a été utilisée pour l'objet. Oui, mais cette façon de faire limite les possibilités d'édition ultérieures : - un objet pourrait avoir plusieurs ref (par exemple un ref:insee et un ref:FR:code-commune) - un objet peut avoir plusieurs sources : un SIG territorial à l'origine, puis une retouche par Bing ou par le cadastre et le source=Mairie d'Orange irait mieux sur le changeset Du coup, ref:source me semble trop fragile. Je pense que ref:FR:code insee commune comme proposé par Philippe Verdy est le plus sûr. -- ° /\Guillaume AllègreOpenStreetMap France /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative / /~~\tél. 04.76.63.26.99 http://www.openstreetmap.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 30/03/2013 22:35, Guillaume Allegre a écrit : Le sam. 30 mars 2013 à 21:45 +0100, Vincent de Chateau-Thierry a écrit : Ensuite : ref:orange : là, je pense qu'on a un problème à régler. orange n'est pas suffisamment distinctif. Si toutes les communes du monde se mettent à utiliser le même schéma, on va multiplier les conflits. Comment régler ça ? Pour éviter d'avoir 36.000 tags ref:* distincts à terme (on peut rêver), je verrais plutôt un schéma générique sur 2 tags : source=* (rien de nouveau ici) ref:source=* ou source:internal_id ou toute autre formulation pour dire la même chose : mentionner l'identifiant unique utilisé par le fournisseur. Dans l'exemple du way : source=Mairie d'Orange 2012 ref:source=84087V99 Après tout, il ne s'agit pas d'un tag ref pour l'objet, que tout un chacun pourrait trouver sur le terrain, mais d'un tag ref qui n'existe que parce qu'une certaine source a été utilisée pour l'objet. Oui, mais cette façon de faire limite les possibilités d'édition ultérieures : - un objet pourrait avoir plusieurs ref (par exemple un ref:insee et un ref:FR:code-commune) - un objet peut avoir plusieurs sources : un SIG territorial à l'origine, puis une retouche par Bing ou par le cadastre et le source=Mairie d'Orange irait mieux sur le changeset Du coup, ref:source me semble trop fragile. Je pense que ref:FR:code insee commune comme proposé par Philippe Verdy est le plus sûr. Avec le schéma ref:FR:code insee commune on pourrait se retrouver avec autant de clés que de communes, toutes signifiant grosso-modo la même chose : cette clé a pour valeur une référence interne à la commune XXX. À l'extrême, 36.000 communes, 36.000 clés ? Je sais bien qu'on n'en arrivera pas là, je pousse juste la logique au bout. Et côté modélisation, autant de clés distinctes qui disent toutes la même chose, je trouve que ça fait beaucoup. Et dans ce scenario catastrophe, imagine le schéma de réutilisation, dans un modèle mis à plat comme le schéma standard d'osm2pgsql : 36.000 colonnes rien que pour la source... Et c'est aussi, à sa manière, fragile. Quid de plusieurs sources issues de la même ville (on a facilement le cas sur les grandes villes) : la source des espaces verts, celle de la voirie, etc. Pour peu que les plages de valeurs se recoupent, le tag ref:FR:insee n'a plus de valeurs uniques dans la même ville, le bénéfice de tracer la source est perdu. Ma proposition sur 2 tags a pour objectif, au moins, d'éviter la multiplicité des clés signifiant toutes la même chose. Je suis d'accord sur le fait que ça ne gère pas le multi-sources. Mais en même temps, est-ce que sur ces objets on n'est pas, quasi par principe, face à du mono-source ? Des objets issus d'un SIG communal, tracés comme tels, sont potentiellement maintenus côté OSM grâce au lien avec la base source, justement. Et si besoin, rien n'empêche d'aller un cran plus fin dans le détail, en sourçant chaque clé plutôt que l'objet dans sa globalité. On a déjà des paquets de source:addr:postcode et des source:ref:INSEE, sur le même principe. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Si on se reposait les questions de base ? A quoi servent ces ref:xxx ? Si il s'agit de maintenir un lien avec un jeu de données externes bien précis et d'une façon unique, il faut que la clé permettent d'identifier le jeu de données sans ambiguité et donc il faut qu'elle soit unique pour chaque jeu de données et un quelque chose du genre ref:insee:x me semble adapté. Ca donne en plus un lien vers le producteur de ce jeu de données x pouvant décrire une région, un département, un EPCI, une commune, voire même une entreprise par son SIREN/SIRET. Si par contre ces références ont un caractère plus global et qu'elles sont utilisables sans être liées à un jeu de données particulier, alors là il faut utiliser une clé qui elle aussi ne soit pas liée à un jeu de données. Si on veut identifier une référence qui serait par exemple donnée de façon homogène par un niveau administratif particulier, on pourrait envisager un ref:admin_level:xx=* Vous allez voir qu'on va y arriver aux linked data ;) -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013ynthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 30 mars 2013 22:26, Guillaume Allegre allegre.guilla...@free.fr a écrit : Le sam. 30 mars 2013 à 21:58 +0100, Philippe Verdy a écrit : Le 30 mars 2013 20:37, Guillaume Allegre allegre.guilla...@free.fr a écrit : 3) La relation 2649371 a des attributs bizarres : - pas de nom - un CANTON=Ouest pas documenté - un ref=22 pas documenté non plus En effet, on a un schéma déja existant et homogène utilisant le code Insee complet du canton à 4 chiffres dans ref:INSEE=*. avec boundary=political, political_division=canton, name=Orange-Ouest, wikipedia=fr:Canton d'Orange-Ouest Je reconnais que mon exemple était ambigu, mais la relation n'est pas un canton, mais la limite d'un bureau de vote (numéro 22), qui appartient au Canton Ouest. Oui mais le nom donné semble indique que le bureau 22 correspond en fait à la même chose que la fraction du canton sur le territoire de la commune. Hors un bureau de vote est très souvent beaucoup plus petit qu'un canton ou même qu'une fraction cantonale. Donc le nom donné Canton Ouest était bien ambigu. Et devait bien indiquer bureau de vote n° 22 même s'il appartient à la fraction du canton d'Orange-Ouest sur le territoire de la commune d'Orange. A l'heure actuelle, il n'y a pas de schéma défini pour les bureaux de vote, mais si un schém s'impose cela devrait rester une subdivision du canton dans un autre type de subdivision pour boundary=political. [Il me semble qu'au Royaume-Uni il y a des définitions pour les polling areas.] La question subsidiaire : vaut-il mieux avoir un nom Limite du bureau de vote n°22 (complètement redondant) ou rien ? Pas redondant, mais en tout cas ne pas faire de confusion avec les limites de cantons, et tant que la carte des bureaux de vote de la commune ou du canton n'est pas complètement établie, il est prématuré de vouloir faire une conflation des limites de ces bureaux de vote avec les frontières de communes ou de cantons. [ Il me semble qu'aucun bureau de vote, pour les élections au suffrage universel, ne peut couvrir des territoires de communes différentes ni de cantons différents, ni de circonscriptions législatives différentes, ni de circonscriptions régionales ou européennes différentes, car ce sont les communes qui ont la charge de les organiser (à défaut de moyens, c'est le préfet du département qui fournit les moyens dans la commune pour ses électeurs) ; la question ne se pose pas pour les circonscriptions sénatoriales puisque pour les sénatoriales les votes ne sont pas organisés par les communes mais par les départements, pour les électeurs élus territoriaux, ou par les régions pour les électeurs élus régionaux, par le biais su suffrage indirect qui fonctionne très différemment et n'est pas lié directement aux territoire de vie des citoyens électeurs Mais ces bureaux de vote ne sont pas des subdisivions administratives, et devraient rester dans des boundary=political avec un type différent pour political_subdivision. ]. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] export d'extraits
Hola, JB, quelle serait l'étendue de la zone que tu souhaiterais exporter. En terme de développement, je suis un peu pris en ce moment. Néanmoins, je planifie d'apporter des modifications à osm2gis d'ici un mois ou deux. Donc c'est le moment de remplir le cahier de doléances :) Arnaud On 30/03/2013 14:01, sly (sylvain letuffe) wrote: Le samedi 30 mars 2013 15:37:41, JB a écrit : En décembre, on parlait d'exports d'extraits de la base, à la manière de géofabrik, mais avec la possibilité de définir sa zone (http://www.mail-archive.com/talk-fr@openstreetmap.org/msg51934.html). Certains avaient l'air bien partants. Ce lien vers un de mes messages faisait référence à osm2gis qui est opérationnel ici : http://www.osm974.re/osm2gis/ Sauf erreur, il utilise désormais bien la base osm2pgsql monde des serveurs de l'association osm-f Arnaud, son auteur, pourra sûrement en dire plus. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Abus des landuse=residential ?
Vincent, Je comprends mieux maintenant la différence. D'autant plus si, comme le souligne Jean-François nous ne sommes pas autorisé à le faire. Néanmoins, fusionner l'ensemble des données c'est un peu violent non? Nous pourrions commencer à entamer une discussion avec le contributeur afin de lui expliquer notre démarche. Arnaud On 29/03/2013 17:47, Vincent Pottier wrote: Le 29/03/2013 18:56, arnaud@gmail.com a écrit : Vincent, J'ai du mal à comprendre en quoi est-ce un abus? Je comprends ta position, mais ce n'est pas pire que d'ajouter le numéro de boite aux lettres non? A. Bonne question... Je le sens et j'essaie de comprendre. Je réfléchis à haute voix... Nous ne mettons pas le numéro de boite aux lettres mais le numéro dans la rue. C'est à dire une information géographique ponctuelle : le n° N est ici. Peu importe le nombre de boites aux lettres : une seule probablement pour un pavillon, 15-20 pour une entrée d'immeuble. Ce numéro, qui est aussi l'adresse postale, est d'abord une adresse géographique, une adresse civile : le numéro tant de la rue machin de la commune truc. Ce n'est pas la poste qui nous a attribué le numéro, mais la commune. De plus c'est un élément ponctuel. C'est à dire qu'il comporte en lui même peu d'information géographique sinon une latitude et une longitude. L'information sur un champ m'intéresse. Que le champ de colza fasse telle surface, que le verger ait telle forme, ça m'intéresse. Mais qu'il soit sur une, deux ou quinze parcelles, cela ne me regarde pas (du point de vue OpenStreetMap). En entrant le découpage parcellaire, on change la nature des données. On n'est plus seulement dans l'information géographique, présence limites réelles ou administratives, d'objets réels ou publics. On introduit des données non matérielles privées. Certes, j'ai entré un certain nombre de numéros de téléphones (contact:phone) mais seulement pour des entreprises. Et le numéro de téléphone est une interface publique de ces entreprises privées. Comme le numéro dans la rue. La limite de propriété est une information sur une personne privée (physique ou morale) qui n'est pas de l'ordre de cette interface publique. Peut-être est-ce cette notion, floue, qui me faisait écrire au feeling que la limite de l'espace public/privé m'intéressait. Mais pas au delà. Derrière le numéro de téléphone, je ne dirai pas s'il y a un ou quinze postes. Derrière le numéro dans la rue, je ne dirai pas quelle est la taille de la propriété (même si le mur de clôture, information sur un objet réel, le suggère). Je dirai le mur, pas la parcelle. Voila pour ce soir. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 30 mars 2013 23:14, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 30/03/2013 22:35, Guillaume Allegre a écrit : Le sam. 30 mars 2013 à 21:45 +0100, Vincent de Chateau-Thierry a écrit : Ensuite : ref:orange : là, je pense qu'on a un problème à régler. orange n'est pas suffisamment distinctif. Si toutes les communes du monde se mettent à utiliser le même schéma, on va multiplier les conflits. Comment régler ça ? Pour éviter d'avoir 36.000 tags ref:* distincts à terme (on peut rêver), je verrais plutôt un schéma générique sur 2 tags : source=* (rien de nouveau ici) ref:source=* ou source:internal_id ou toute autre formulation pour dire la même chose : mentionner l'identifiant unique utilisé par le fournisseur. Dans l'exemple du way : source=Mairie d'Orange 2012 ref:source=84087V99 Après tout, il ne s'agit pas d'un tag ref pour l'objet, que tout un chacun pourrait trouver sur le terrain, mais d'un tag ref qui n'existe que parce qu'une certaine source a été utilisée pour l'objet. Oui, mais cette façon de faire limite les possibilités d'édition ultérieures : - un objet pourrait avoir plusieurs ref (par exemple un ref:insee et un ref:FR:code-commune) - un objet peut avoir plusieurs sources : un SIG territorial à l'origine, puis une retouche par Bing ou par le cadastre et le source=Mairie d'Orange irait mieux sur le changeset Du coup, ref:source me semble trop fragile. Je pense que ref:FR:code insee commune comme proposé par Philippe Verdy est le plus sûr. Avec le schéma ref:FR:code insee commune on pourrait se retrouver avec autant de clés que de communes, toutes signifiant grosso-modo la même chose : cette clé a pour valeur une référence interne à la commune XXX. À l'extrême, 36.000 communes, 36.000 clés ? Je sais bien qu'on n'en arrivera pas là, je pousse juste la logique au bout. Et côté modélisation, autant de clés distinctes qui disent toutes la même chose, je trouve que ça fait beaucoup. Et dans ce scenario catastrophe, imagine le schéma de réutilisation, dans un modèle mis à plat comme le schéma standard d'osm2pgsql : 36.000 colonnes rien que pour la source... Là tu pousses à l'extrême car ces clés ne sont pas destinées à devenir des features au sens OpenGIS, mais des métadonnées à distinguer parmi celles pouvant renseigner un objet GIS. Hors on se retrouvera vite avec des clés fournies ou référencées par deux collectivités différentes, par exemples sur les voiries partagées par deux communes (ou plus). Si chacun a sa propre référence dans son SIG, on fait comment ? Même si une seule des sources a été utilisée (les autres sont d'accord sur le tracé, il n'y a pas d'ambiguité que c'est bien le même objet référenc, chaque source devrait pouvoir faire le lien avec son propre système de référence, car il n'y a pas garantie que les références utilisées par un SIG soient les mêmes que celle du SIG voisin (à moins qu'il y ait une convention commune adoptée entre les collectivités pour qu'elles utilisent la même référence interne pour faciliter les échanges entre les collectivités). Si ces collectivitées sont deux communes d'une même EPCI, elles se mettront d'accord avec le SIG de l'EPCI qui fera la lien. Mais il restera tout de même encore des liaisons à faire entre les SIG de deux EPCI différents, ou d'un EPCI et d'une commune hors EPCI. Ces communes peuent être aussi dans un autre département ou une autre région. Quand je proposais ref:FR:numéro insee = *, il était évident qu'on pouvait y mettre toute référence insee : un département à deux chiffres/lettres, une commune à 5 chiffres, mais si nécessaire on doit pouvoir être plus précis et indiquer le type de collectivité : - ref:FR:région:numéro insee = * - ref:FR:département:numéro insee = * - ref:FR:commune:numéro insee = * - ref:FR:EPCI:numéro insee = * Si au sein de la même collectivité il peut y avoir plusieurs sources utilisant des numéros de référence différents (service des espaces verts d'une commune par exemple), on peut sous-qualifier: - ref:FR:EPCI:numéro insee:esp-verts = * Note: les références nationales pour désigner les territoires entiers des collectivités elles-mêmes (ou autres subdivisions administratives voire aussi les cantons) restent: - ref:INSEE = numéro INSEE Les académies pourraient avoir leurs propre références pour les établissements qu'elles gèrent: - ref:FR:académie:Nom=* Chacun a sa clé de référence pour faire la liaison avec son SIG. Idem pour les régions militaires (mais là je pense qu'on n'a pas accès aux références internes, et que c'est géré en fait par le ministère de la défense, y compris pour les gendarmeries) Ma proposition sur 2 tags a pour objectif, au moins, d'éviter la multiplicité des clés signifiant toutes la même chose. Cela ne multiplie pas les clés. Les ref:* ne sont pas des features au sens GIS se ne sont que des métadonnées attachées en complément à un autre feature. Et les ref indiquées ne sont pas non plus nécessairement les
Re: [OSM-ja] OSC会場での話題(Android版でよいOSMツール)
On 2013/03/08, at 23:10, Hiroshi Miura(osmf) miur...@osmf.jp wrote: Zoom levelは限界に思います。なぜかというと、osm.orgのレンダリングでは、PC用にzoom18が上限。 ほんとは、 Android deviceのスペックに会わせたレンダリングを独自にすべきですが、アプリはそこまではしていない。 三浦 iPadのGallieoと比べてみました。 Galleoだといちばん下の目盛りが50mになるのが一番拡大したレベルのようです。 AndroidのRmapsも同じです。しかし、Gallieoの場合は、地図のズームレベルはそのままで、 さらにズームすることができます。そのため、細かな部分がうまく読みとれます。 目盛りも20m,10mと変わります。 Androidではできません。不便なんです。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] 地下道の入口はどう書けばいいでしょう?
地下鉄の入口とはちょっと違いますし、 entrance=underpass でしょうか? oota ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 地下道の入口はどう書けばいいでしょう?
東です。 2013/03/30 ribbon o...@ns.ribbon.or.jp: 地下鉄の入口とはちょっと違いますし、 entrance=underpass でしょうか? ちゃんとしたものは無いようですね。上記も一案かと思いますが 多少使われている highway=entrance はいかがでしょうか。 http://taginfo.openstreetmap.org/tags/highway=entrance#overview oota ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 地下道の入口はどう書けばいいでしょう?
On Sat, Mar 30, 2013 at 11:00:44PM +0900, Shu Higashi wrote: 東です。 2013/03/30 ribbon o...@ns.ribbon.or.jp: 地下鉄の入口とはちょっと違いますし、 entrance=underpass でしょうか? ちゃんとしたものは無いようですね。上記も一案かと思いますが 多少使われている highway=entrance はいかがでしょうか。 http://taginfo.openstreetmap.org/tags/highway=entrance#overview でも、地下道の入口が独立した建物(?)になっている場合、 highway を付けるのはちょっとと思うのですが、どうでしょうか。 たとえば、 http://www.openstreetmap.org/?lat=35.686991lon=139.694483zoom=18layers=M の、ドトールの道路挟んだ向かいにある、細長いものは、道路上にある、 地下道への入口です。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
