Re: [Talk-es] [Cat2Osm2] Simplificación de nodos
Hola, Disculpad que no haya dado señales de vida, no vuelvo a decir en voz alta eso de que 'voy a tener tiempo libre', que parece que se compinchan todos para evitarlo :-D Estoy leyendo los correos de este par de días. Me pasa como a otros compañeros, que no veo las imágenes que habéis enviado. En cualquier caso, lo de los miles de nodos en círculos y semicírculos estuve tentado de corregirlo a mano, creo que tendría que haberlo hecho porque sí que es verdad que aparecen demasiados. Al final no lo hice porque evidentemente al reducir el número de nodos, no queda tan 'redondito' y decidí dejarlo como lo sacaba Cat2Osm2. En cualquier caso, cuando saque un ratillo lo corregiré en los datos ya subidos a OSM. Un saludo, -- Antonio Navarro mailto:anto...@hunos.net mailto:antonio.navarro...@gmail.com mailto:antonio.nava...@hispalinux.es El 28 de febrero de 2013 13:50, andrzej zaborowski escribió: > Hola, > > 2013/2/26 Cruz Enrique Borges Hernandez : > >> Pienso que lo correcto es detectar los nodos limites de tramos > >> compartidos por las vías, es decir los nodos pertenecientes a mas de > >> una vía, pero donde el nodo siguiente o anterior ya no pertenece al > >> mismo numero de vías. Lo que hay que hacer es simplificar cada uno de > >> estos tramos por separado, de esta manera nos aseguramos de que si el > >> algoritmo decide eliminar un conjunto de nodos, se eliminan los mismos > >> nodos en todas las vías que comparten el tramo ya que las distancias > >> van a ser idénticas. A ver si lo conseguí explicar bien. > > > > Se entiende perfectamente, el problema es que la simplificación de nodos > > se hace mucho antes de saber ese tipo de información para que luego todo > > sea más simple. De hecho, de hacerlo más tarde tenemos problemas como > > que los portales desaparecen :S > > > > En algún momento escribimos un código que hacía la simplificación de > > nodos, supongo que es hora de buscarlo de nuevo y meter un > > a cadena de if con las condiciones para no hacerlo :S > > No digo que lo que proponéis en el mail original esta mal, pero las > imágenes no las podía ver. Al final mejor que decidan los que van a > hacer la importación. > > Saludos > > ___ > Talk-es mailing list > Talk-es@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-es > ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Iniciativa #NoNosVamosNosEchan usando OSM?
Hola, No soy ningún experto, pero hay una librería Javascript para incrustar mapas en webs que permite usar varios proveedores de mapas (OSM, Google o cualquier servicio WMS, al menos eso creo). La librería es OpenLayers ( http://openlayers.org/) y tienen ejemplos en la web para hacer casi todo, incuso mostrar marcadores mediante un fichero KML. Hay otra librería http://leafletjs.com/ que tiene también buena pinta, aunque no he trasteado con ella (con la primera sólo he incrustado un mapa en una web, tampoco he hecho mucho). Un saludo, -- Antonio Navarro mailto:anto...@hunos.net mailto:antonio.navarro...@gmail.com mailto:antonio.nava...@hispalinux.es El 28 de febrero de 2013 20:23, Jimena Martínez < jimena.marti...@sinfogeo.com> escribió: > Buenas > Estaba trasteando por esta web: > http://www.nonosvamosnosechan.net/ > > Y he visto que tienen un problemilla con Google Maps. A parte de ser > Google, > digo. > Es porque solo les permite 200 localizaciones, y he pensado que aunque esto > tendrá fácil solución seguro, igual se les podría proponer usar OSM y cómo > hacerlo. Yo no tengo ni idea de cómo debería programarse pero estoy casi > segura de que puede hacerse. Supongo que igual también se podría > automatizar > el proceso, permitiendo que desde el formulario se actualicen las > historias, > ahora hay alguien detrás currándose el KML cada tanto... Me refiero a algo > tipo crowdmap pero que lo puedan seguir manteniendo en su web, que imagino > que es lo que les gustaría. > Alguna idea? Igual hasta hay algo hecho ya, claro. > > Su email es: > nonosvamosnosec...@gmail.com > > Pues nada, gracias y a ver si fuera posible, estaría bien que estas cosas > fueran con OSM y no con Google, creo yo. > > Saludos > > Jimena > > > > > ___ > Talk-es mailing list > Talk-es@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-es > ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
[Talk-es] Iniciativa #NoNosVamosNosEchan usando OSM?
Buenas Estaba trasteando por esta web: http://www.nonosvamosnosechan.net/ Y he visto que tienen un problemilla con Google Maps. A parte de ser Google, digo. Es porque solo les permite 200 localizaciones, y he pensado que aunque esto tendrá fácil solución seguro, igual se les podría proponer usar OSM y cómo hacerlo. Yo no tengo ni idea de cómo debería programarse pero estoy casi segura de que puede hacerse. Supongo que igual también se podría automatizar el proceso, permitiendo que desde el formulario se actualicen las historias, ahora hay alguien detrás currándose el KML cada tanto... Me refiero a algo tipo crowdmap pero que lo puedan seguir manteniendo en su web, que imagino que es lo que les gustaría. Alguna idea? Igual hasta hay algo hecho ya, claro. Su email es: nonosvamosnosec...@gmail.com Pues nada, gracias y a ver si fuera posible, estaría bien que estas cosas fueran con OSM y no con Google, creo yo. Saludos Jimena ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Trazado y etiquetado de la superficie de calles
Le veo mas desventajas que ventajas: -Ventajas: * Indicar la superficie, pero piensa que las calles en general tienen un ancho específico por carril, en el carril ya estás indicando cuantos carriles tiene esa calle. Aquí tienes información sobre el ancho de los carriles: http://www.carreteros.org/ccaa/legislacion/carreteras/pv/normativa/2_4.htm El ancho de los carriles no suele variar, lo que puede variar es la acera o el aparcamiento en batería o en línea * "Mas bonito" en el renderizado, se debe mapear en función de utilidad no en función de lo bonito que quede. - Desventajas: * No son ruteables, los gps y los programas de calculo de rutas no trabajan con ello. * Las aceras deben ir independientes de los carriles ya que puede existir aparcamientos, jardines o lo que se te ocurra entre ello. * Visualmente creo que puede liar al no saber exactamente por donde va el carril, se podrían confundir con plazas. Respecto a las aceras, creo que son "footway" en lugar de "kerb" que es rebaje http://wiki.openstreetmap.org/wiki/Footway http://wiki.openstreetmap.org/wiki/Proposed_features/kerb Un saludo Óscar (aka cronoser) Tengo interés en revisar mi zona de manera que quede perfectamente delimitado lo que es calle, acera, jardín y edificio. Es decir, trazar las calles como superficies y no como líneas. -Mensaje original- From: Noel David TorresTaño Sent: Thursday, February 28, 2013 7:13 PM To: talk-es@openstreetmap.org Subject: Re: [Talk-es] Trazado y etiquetado de la superficie de calles ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Trazado y etiquetado de la superficie de calles
On Jueves, 28 de febrero de 2013 07:23:47 Ander Pijoan wrote: > Hasta donde yo se, las carreteras no deben hacerse nunca como áreas. Eso (a > parte de que no aporta ninguna ventaja), no sirve para los navegadores o > ruteadores. Si quieres lo que si puedes ponerles es un tag con la anchura, > cuantos carriles tienen, si tienen acera, si están preparadas para gente en > silla de ruedas, etc. La ventaja sería que queda definida la superficie que ocupan. Saludos Noel er Envite - A: Because it breaks the logical flow of discussion. Q: Why is top posting bad? signature.asc Description: This is a digitally signed message part. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] [Cat2Osm2] Simplificación de nodos
Hola, 2013/2/26 Cruz Enrique Borges Hernandez : >> Pienso que lo correcto es detectar los nodos limites de tramos >> compartidos por las vías, es decir los nodos pertenecientes a mas de >> una vía, pero donde el nodo siguiente o anterior ya no pertenece al >> mismo numero de vías. Lo que hay que hacer es simplificar cada uno de >> estos tramos por separado, de esta manera nos aseguramos de que si el >> algoritmo decide eliminar un conjunto de nodos, se eliminan los mismos >> nodos en todas las vías que comparten el tramo ya que las distancias >> van a ser idénticas. A ver si lo conseguí explicar bien. > > Se entiende perfectamente, el problema es que la simplificación de nodos > se hace mucho antes de saber ese tipo de información para que luego todo > sea más simple. De hecho, de hacerlo más tarde tenemos problemas como > que los portales desaparecen :S > > En algún momento escribimos un código que hacía la simplificación de > nodos, supongo que es hora de buscarlo de nuevo y meter un > a cadena de if con las condiciones para no hacerlo :S No digo que lo que proponéis en el mail original esta mal, pero las imágenes no las podía ver. Al final mejor que decidan los que van a hacer la importación. Saludos ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] [Imports] [Cat2Osm2] Tool for exporting Spanish Cadastre data in OSM suitable format
We are thankfull for your corrections but we want to make clear that this is NOT an automated import tool, it is a HELP tool to improve the information. These fixme are put in order to OBLIGATE the local mapper that is ussing the tool to correct the mistakes BEFORE upload. WE INSIST, THIS IS NOT AN AUTOMATIC IMPORT TOOL. [sorry for the upper case, but it seems that it is easily forgot...]. We aswer below. > I see lots of FIXME keys, and also FIXME values on that page. I don't > think that there's much merit in automatically adding fixme tags. For > things like "landuse=commercial, office=fixme" then the lack of an > office tag will be picked up by QA tools. This is exactly the objetive of these tags. > As for particular sections: > > * Commercial - (C) - I would find it unusual to see both a landuse and > shop tags on a particular feature - if it's a shop, then the landuse > tag is either redundant, or I would expect to find it on a separate > way surrounding a group of shops. > * shop=pharmacy should be amenity=pharmacy Perfect, we will change that. > * Turismo - (G) - "amenity=cafe, forks=4" I have no idea what forks=4 > means, but looking at hotels I think it's some sort of award rating. > An alternative key should be used, unless the cafe has only 4 items of > cutlery! This is what the spanish comunity have agreed. In Spain the Restaurant awars are "tenedores" (forks). Is you think that it would be better to put "stars" we can change this but it would collide with the Michelin "stars". Or you suggest using something like "cafe:awards" or similar? > * tourism=apartments, category=1 - again, a better key for the > "category" is needed. In Spain apartmens have a "Llave" (key) as a category. We have the same question, it is better to have a "key" tag, a "category" tag or use the "stars" tag (same as hotels)? > * Deportivo (K) - landuse=sports - that's not an in-use value for > landuse, so I wouldn't use it. Ok, we will change it for leisure=sport_centre. > * Oficinas (O) - similar to the commercial section, I wouldn't add > landuse tags to individual offices. Additionally, landuse=health isn't > a recognised tag Perfect, we will change that. > * Sanidad, beneficiencia y otros (Y) - I don't know what is meant by > "medical_system:western=yes", I'd suggest not using it > * "health_facility:type=clinic" - this just duplicates the information > in the amenity=clinic tag, so should be removed > * "landuse=health, health_facility:type=dispensary" - I suspect this > is better tagged with amenity=pharmacy, dispensing=yes > * health_facility:type=hospital - that just duplicates the > amenity=hospital tag, so should be removed Perfect, this is what local mapper have thought would be best, but reading you comments we think that your suggestion make sense. > * office=labor_union - we use en_gb spellings, so office=labour_union please OK > * landuse=farmyard, building=livestock - I'd say it's either a > building or an area of farmyard, but not both. See landuse vs office, > above Perfect. > Cheers, > Andy We will change that tags ASAP in the wiki and in the tool. Thankyou. -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
