Re: [Talk-es] Conseguir PNG

[konan1986]

A ver..yo me descargo el xml de la pag de osm y desde aqui con la hoja de
estilo me fabrico el svg y del este con un programa de imagenes consigo el
png.. todos esto  mediante la cmd de windows...
MI problema no es este..yo quiero ejecutar este en vez de en la cmd de
windows en java... ahora bien...cuando lo intento ejecutar desde java, el
programa que me pasa de xml a svg con la hoja de estilo se me queda
pillado.. me han dicho que es por  que al ejecutarlo en java se redirigen
los buffers de salida y entrada del programa que se ejecuta ...y como el
programa que ejecuto vuelca el resultado sobre un nuevo archivo:
c:\\xml tr c:\\osmarender.xsl >map.svg
pues se queda ahi parado porque los buffer de java se llenan y no soy capaz
de vaciarlos, aunque lo intento:
String aux1="c:\\xml tr c:\\osmarender.xsl osm-map-features-z17.xml";
Process p1 = Runtime.getRuntime().exec(aux1);
InputStream is1=p1.getInputStream();
OutputStream out = new FileOutputStream("map.svg");
byte[] buffer = new byte[256];
while (true) {
int n = is1.read(buffer);
if (n < 1) {
break;
}
out.write(buffer, 0, n);
}
   is1.close();
out.close();


por eso os preguntaba alguna otra alternativa sencilla y parecida
-- 
View this message in context: 
http://www.nabble.com/Conseguir-PNG-tp22783878p22805216.html
Sent from the OpenStreetMap - Spanish Talk mailing list archive at Nabble.com.


___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Mapas de cobertura sobre OpenStreetMap

[Carlos Dávila]

Jonas Andradas escribió:
> Buenas,
>
> ya me respondo yo solo, que lo he descubierto medio de casualidad :)
>
> Si se selecciona toda la tabla (todas las columnas y todas las filas),
> y luego se selecciona el título de la columna que nos interesa, la
> expresión se aplica a todas las filas de dicha columna :)
>   
Aunque ya lo hayas resuelto, te comento otra forma, por si es útil.
Abre el dbf en Calc y cambia la cabecera de la columna que te interese
de "Nombre,C,longitud" a
"Nombre,N,longitud_parte_entera,longitud_parte_decimal"

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Mapas de cobertura sobre OpenStreetMap

[Jonas Andradas]

Buenas,

ya me respondo yo solo, que lo he descubierto medio de casualidad :)

Si se selecciona toda la tabla (todas las columnas y todas las filas),
y luego se selecciona el título de la columna que nos interesa, la
expresión se aplica a todas las filas de dicha columna :)

Un saludo,

Jonás.

2009/3/31 Jonas Andradas :
> Muy buenas,
>
> 2009/3/31 Carlos Dávila :
>> Jonas Andradas escribió:
>>> Buenas de nuevo,
>>>
>>> me estoy encontrando con alguna dificultad, supongo que de mi poca
>>> (errr.. nula) experiencia con gvSIG:
>>>
>>>
 2009/3/26 Juan Guillermo Jordán Aldasoro :

>>> (...)
>>>
> Para gvSIG lo mejor sería partir del fichero CSV. Hay una forma de 
> importar
> ficheros CSV a shapefile.
>
> Crear una nueva tabla (tabla->nuevo->csv string). El CSV debe estar 
> separado
> por ";" en lugar de "," o no funcionará :-( . Puedes cambiar esto 
> fácilmente
> con un editor de texto.
>
 El CSV del Kismet ya los trae así, así que ni siquiera tengo que
 reemplazarlos :)


> Crear una nueva vista. Menu vista->añadir capa de eventos.
> En el dialogo seleccionar la tabla (si es que has abierto más de una) y 
> los
> campos que constituyen latitud y longitud en tu tabla.
> Ya tienes la capa shapefile.
>
>
>>>
>>> Esto ya lo tengo :)
>>>
>>>
>     * Otros XMLs con esta información agrupada de diferentes formas,
> pero creo que los más interesantes son los anteriores.
>
>
>
> Haces el geoproceso correspondiente, por ejemplo un buffer.
>
>
> Esta parte es donde estoy más verde.  Pensaba que un "geoproceso" era
> un proceso (como un script) para "procesar" (valga la redundancia)
> datos georreferenciados.  Pero al decir lo del "buffer" me he perdido,
> y creo que estoy entendiéndolo mal.  Por otra parte, no tengo ni idea
> de cómo hacer un geoproceso, así que tengo aprender :P  ¿los
> geoprocesos son específicos de cada SIG? ¿Cómo has hecho el que envías
> en el correo?
>  Agradezco cualquier ayuda :)
>
>
>
> En gvSIG se haría de la siguiente manera (pasos aproximados, para más
> detalles ver manual):
>
> Con la capa shape seleccionada, pulsar menu de geoprocesos (un boton en la
> barra de herramientas, o el menu vista->gestor de geoprocesos).
> Te aparece una lista de geoprocesos. Selecciona uno de los primeros, se
> llama buffer o área de influencia. Este geoproceso "engorda" las 
> geometrías,
> si es un punto crea un círculo, si es una línea un churrito :-P
> Aparece un diálogo. Hay varias opciones, puedes escoger un tamaño fijo 
> para
> el buffer, o sea, el radio de los círculos, porque en este caso tus
> geometrías serán puntos. También puedes seleccionar un campo de tu 
> shapefile
> para que cada círculo tenga un radio. En la prueba que hice para enviar el
> dibujo fije yo manualmente un radio para cada círculo. El problema es que
> siempre toma el valor como metros, creo. O sea que si tú tienes decibelios
> es posible que te pinte círculos muy grandes, y no conozco la forma de 
> hacer
> que cambie la proporción (Quizás podrías modificar el CSV con excel para
> tener una columna cuyo valor sea decibelios/algo).
>
>>>
>>> Aquí es donde viene mi problema.  Como alcance, tenía un número
>>> decimal bastante "largo", del estilo de "30.45712393734458".  Al
>>> intentar seleccionar el campo "Cobertura" para el radio de los
>>> círculos, obtengo un mensaje de error que dice que no es un campo
>>> numérico.  He cambiado el script en Perl con el que hago el CSV para
>>> que me redondee este número a dos dígitos decimales, y sigo obteniendo
>>> el mismo error.  Sin embargo, si indico yo a mano un radio, se come
>>> toda la imagen incluso poniendo como radio "1".  O bien no estoy
>>> importando la capa de latitud y longitud bien, o el radio no son
>>> metros, o yo no lo he entendido :)  Si pongo como radio "0.00150", al
>>> menos veo círculos y zonas blancas, pero creo que siguen siendo
>>> demasiado grandes.  ¿Alguien sabe qué puedo estar haciendo mal?  Voy a
>>> intentar añadir una capa de WMS para ver si veo realmente dónde me
>>> estoy equivocando.  ¿Por qué un radio de "30.23" del campo "Cobertura"
>>> (alcance, realmente) no lo coge?  ¿Puede tener que ver que esté usando
>>> EPSG 23030?
>>>
>> Revisa la definición de los campos de la tabla (el .dbf). En ocasiones
>> me ha pasado algo parecido y era porque el campo en cuestión estaba
>> definido como string, no como numérico.
>>>
>
> Efectivamente, el campo es de tipo string.  Pero no me deja modificar
> la tabla y ponerlo como "Double", sino que tengo que crear una columna
> nueva.  No he sabido copiar toda una columna (la de string) a la
> nueva, double, salvo elemento a elemento.  ¿Hay alguna forma mejor de
> hacerlo?  He visto que se pueden poner expresiones como
> "toNumber([Cobertura])", en la nueva co

Re: [Talk-es] intersección rotonda con puentes y rel ación de prohibición de giro

[Carlos Dávila]

Pablo Gómez escribió:
> sergio sevillano escribió:
>   
>> Pablo Gómez escribió:
>>   
>> 
>>> Carlos Dávila escribió:
>>>   
>>> 
>>>   
 Celso González escribió:
   
 
   
 
> On Fri, Mar 27, 2009 at 10:56:59PM +0100, Carlos Dávila wrote:
>   
> 
>   
> 
>   
>> sergio sevillano escribió:
>> 
>>   
>> 
>>   
>> 
>>> yo creo que es correcto partir la rotonda en cuatro partes para poner 
>>> los puentes. [1]
>>>
>>> pero puede entrar en conflicto con relaciones de prohibición de giro,
>>> que también requiere partir la rotonda, pero por sitios distintos [2]
>>>
>>> alguien tiene un ejemplo resuelto de los dos casos a la vez.
>>> o bien una idea de como hacerlo
>>>
>>> sergio
>>>
>>> [1] 
>>> http://www.openstreetmap.org/?lat=40.4122&lon=-3.8868&zoom=17&layers=B000FTF
>>> [2] 
>>> http://www.openstreetmap.org/?lat=40.494631&lon=-3.648872&zoom=18&layers=B000FTF
>>>
>>> (ya no pregunto más, hoy)
>>>   
>>> 
>>>   
>>> 
>>>   
>> Creo que puedes partirla todas las veces que te haga falta. Con mantener
>> en todos los trozos juntion=roundabout seguirá siendo una rotonda. De
>> todas formas, en los dos ejemplos que pones no veo que haya ningún
>> conflicto.
>> 
>>   
>> 
>>   
>> 
> Y en este caso los oneway=yes hacen innecesario el uso de restricciones 
> de giro, creo
>
>   
> 
>   
> 
>   
 En el ejemplo [2] si pueden ser necesarias, porque es posible que no
 esté permitido girar a la izquierda desde los tramos de rotonda entre
 las dos vías paralelas, sino que te obligen a girar media rotonda para
 incorporarte (no sé si se entiende).

   
 
   
 
>>> Correcto, aquí si necesitas restricciones. Pero en este caso, la rotonda
>>> es "urbana" y el link de la motorway muere en ella. Y no hay puentes.
>>>
>>> Por otra parte, supongo que existe la posibilidad de encontrar todas las
>>> opciones juntas, y quizá en ese caso la respuesta es que puedes romperla
>>> todas las veces que necesites. Supongo que después el cálculo del "tome
>>> la tercera salida" será más complejo...
>>>
>>> Pablo
>>>
>>>
>>> ___
>>> Talk-es mailing list
>>> Talk-es@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-es
>>>
>>>   
>>> 
>>>   
>> Como podéis ver ya se ha resuelto el tema de la rotonda.
>> lo has hecho tú, Pablo?
>> bueno mando un par de links
>> de como se comporta un navegador con ella
>> http://www.yournavigation.org/?flat=40.431268&flon=-3.660639&tlat=40.435591&tlon=-3.659498&v=motorcar&fast=1&layer=mapnik
>> http://www.yournavigation.org/?flat=40.429904&flon=-3.664859&tlat=40.435591&tlon=-3.659498&v=motorcar&fast=1&layer=mapnik
>>
>>   
>> 
>
> No, no he tocado nada. Está claro que en el ejemplo 1 la cosa no
> funciona. Pero eso pasará en todas las uniones (típicas) en V de salida
> de rotonda hacia una vía de doble sentido. Otro ejemplo:
>
> http://www.yournavigation.org/?flat=40.429904&flon=-3.664859&tlat=40.435591&tlon=-3.659498&v=motorcar&fast=1&layer=mapnik
>
> O el rutado funciona mejor, o habrá que establecer restricciones en
> todas las uniones como esa. Hay navegadores comerciales que te permiten
> elegir si quieres tener en cuenta "U turns" o "180s" en el cálculo de tu
> ruta. Desde mi punto de vista, la pelota está más en el lado del navegador.
>   
El problema puede ser que si el ángulo que forman las dos vías de salida
de la rotonda no es lo suficientemente cerrado, no lo considere como
"u-turn".
Con respecto a los ejemplos que habéis comentado, yo hasta ahora no
consideraba que ese tipo de "vías en círculo" fueran rotondas, es decir,
si pasan otras vías por medio yo no las etiqueto como roundabout. Yo
sólo marco como rotonda cuando hay algo en el centro (plaza, fuente,
seto, etc.) que te obliga a girar en círculo hasta la salida que te
interesa. Me podéis aclarar cuál es el criterio correcto?
Saludos
Carlos

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Mapas de cobertura sobre OpenStreetMap

[Jonas Andradas]

Muy buenas,

2009/3/31 Carlos Dávila :
> Jonas Andradas escribió:
>> Buenas de nuevo,
>>
>> me estoy encontrando con alguna dificultad, supongo que de mi poca
>> (errr.. nula) experiencia con gvSIG:
>>
>>
>>> 2009/3/26 Juan Guillermo Jordán Aldasoro :
>>>
>> (...)
>>
 Para gvSIG lo mejor sería partir del fichero CSV. Hay una forma de importar
 ficheros CSV a shapefile.

 Crear una nueva tabla (tabla->nuevo->csv string). El CSV debe estar 
 separado
 por ";" en lugar de "," o no funcionará :-( . Puedes cambiar esto 
 fácilmente
 con un editor de texto.

>>> El CSV del Kismet ya los trae así, así que ni siquiera tengo que
>>> reemplazarlos :)
>>>
>>>
 Crear una nueva vista. Menu vista->añadir capa de eventos.
 En el dialogo seleccionar la tabla (si es que has abierto más de una) y los
 campos que constituyen latitud y longitud en tu tabla.
 Ya tienes la capa shapefile.


>>
>> Esto ya lo tengo :)
>>
>>
     * Otros XMLs con esta información agrupada de diferentes formas,
 pero creo que los más interesantes son los anteriores.



 Haces el geoproceso correspondiente, por ejemplo un buffer.


 Esta parte es donde estoy más verde.  Pensaba que un "geoproceso" era
 un proceso (como un script) para "procesar" (valga la redundancia)
 datos georreferenciados.  Pero al decir lo del "buffer" me he perdido,
 y creo que estoy entendiéndolo mal.  Por otra parte, no tengo ni idea
 de cómo hacer un geoproceso, así que tengo aprender :P  ¿los
 geoprocesos son específicos de cada SIG? ¿Cómo has hecho el que envías
 en el correo?
  Agradezco cualquier ayuda :)



 En gvSIG se haría de la siguiente manera (pasos aproximados, para más
 detalles ver manual):

 Con la capa shape seleccionada, pulsar menu de geoprocesos (un boton en la
 barra de herramientas, o el menu vista->gestor de geoprocesos).
 Te aparece una lista de geoprocesos. Selecciona uno de los primeros, se
 llama buffer o área de influencia. Este geoproceso "engorda" las 
 geometrías,
 si es un punto crea un círculo, si es una línea un churrito :-P
 Aparece un diálogo. Hay varias opciones, puedes escoger un tamaño fijo para
 el buffer, o sea, el radio de los círculos, porque en este caso tus
 geometrías serán puntos. También puedes seleccionar un campo de tu 
 shapefile
 para que cada círculo tenga un radio. En la prueba que hice para enviar el
 dibujo fije yo manualmente un radio para cada círculo. El problema es que
 siempre toma el valor como metros, creo. O sea que si tú tienes decibelios
 es posible que te pinte círculos muy grandes, y no conozco la forma de 
 hacer
 que cambie la proporción (Quizás podrías modificar el CSV con excel para
 tener una columna cuyo valor sea decibelios/algo).

>>
>> Aquí es donde viene mi problema.  Como alcance, tenía un número
>> decimal bastante "largo", del estilo de "30.45712393734458".  Al
>> intentar seleccionar el campo "Cobertura" para el radio de los
>> círculos, obtengo un mensaje de error que dice que no es un campo
>> numérico.  He cambiado el script en Perl con el que hago el CSV para
>> que me redondee este número a dos dígitos decimales, y sigo obteniendo
>> el mismo error.  Sin embargo, si indico yo a mano un radio, se come
>> toda la imagen incluso poniendo como radio "1".  O bien no estoy
>> importando la capa de latitud y longitud bien, o el radio no son
>> metros, o yo no lo he entendido :)  Si pongo como radio "0.00150", al
>> menos veo círculos y zonas blancas, pero creo que siguen siendo
>> demasiado grandes.  ¿Alguien sabe qué puedo estar haciendo mal?  Voy a
>> intentar añadir una capa de WMS para ver si veo realmente dónde me
>> estoy equivocando.  ¿Por qué un radio de "30.23" del campo "Cobertura"
>> (alcance, realmente) no lo coge?  ¿Puede tener que ver que esté usando
>> EPSG 23030?
>>
> Revisa la definición de los campos de la tabla (el .dbf). En ocasiones
> me ha pasado algo parecido y era porque el campo en cuestión estaba
> definido como string, no como numérico.
>>

Efectivamente, el campo es de tipo string.  Pero no me deja modificar
la tabla y ponerlo como "Double", sino que tengo que crear una columna
nueva.  No he sabido copiar toda una columna (la de string) a la
nueva, double, salvo elemento a elemento.  ¿Hay alguna forma mejor de
hacerlo?  He visto que se pueden poner expresiones como
"toNumber([Cobertura])", en la nueva columna "Alcance".  Si lo hago a
través del menú de "Expresiones", se añade bien, pero si escribo eso
tal cual, o con un "=" delante (al estilo de las hojas de cálculo), me
ignora.  Y tampoco puedo (o he sido capaz) de seleccionar toda la
columna de la tabla y asignar dicha expresión a todas las celdas de la
columna.¿Se puede hacer esto de alguna forma?

>>> (...)
>>>
 Puedes decir si quieres que los círculos se fusionen, y si quieres tener
 va

Re: [Talk-es] Mapas de cobertura sobre OpenStreetMap

[Jonas Andradas]

Muy buenas,

está quedando bastante chulo.  Tengo que ajustar el alcance, porque
pese a haberlo pasado de pies a metros, y luego dividirlo por la mitad
(era tan grande que supongo que se refería al diámetro horizontal y
vertical del alcance, no al radio, pero no sé).  Aún así, el alcance
me parece excesivo :)  Voy a ver si lo hago más pequeño.

Las redes se ven directamente al pasar con el coche, pero tendría que
repetirlo otra vez (debería), ya que creo que no podría usar los datos
recogidos durante la auditoría en sitios fuera :P

Un saludo,

Jonás.

2009/3/31 Juan Guillermo Jordán Aldasoro :
> Me alegro de que lo hayas solucionado.
>
> Y ya en otro orden de cosas, si los datos de redes capturadas no son
> privados, considera la opción de subirlas a la base de datos de wigle
> [1] de puntos de acceso. No tienen una licencia tan "guay" como la de
> osm -al parecer no puedes hacer uso comercial de los datos-, pero tienes
> acceso a muchos datos para uso experimental. Yo estuve subiendo varios
> miles de puntos de acceso de Valencia.
>
> Saludos
> Juangui
>


> [1] http://www.wigle.net/
> [2] http://www.wigle.net/eula.html
>
> Jonas Andradas escribió:
>> Buenas...
>>
>> esto... xD sí era la proyección.  Ahora ya se ve bien, y las
>> distancias son de 200 y 300 metros :)
>>
>> ¡¡Muchas gracias!!
>>
>> 2009/3/31 Jonas Andradas :
>>
>>> Buenas,
>>>
>>> 2009/3/31 Juan Guillermo Jordán Aldasoro :
>>>
 En mi ejemplo yo usaba EPSG 4623. Los alcances que yo usaba eran del
 orden de 5-25 'unidades'. Digo unidades porque no tengo claro qué
 representan, en mi caso sí que parecía corresponderse a metros.

>>> Con todos los puntos pintados, cojo la herramienta de distancia y, de
>>> una esquina de los puntos a la contraria, mide 0,01... Me temo que mi
>>> problema va a estar ahí.  Pero no sé qué he hecho mal :(  Adjunto un
>>> pantallazo.
>>>
>>> Voy a probar a cambiar la proyección, pero no creo que sea eso...
>>>
>>>
 Jonas Andradas escribió:

> Buenas de nuevo,
>
> me estoy encontrando con alguna dificultad, supongo que de mi poca
> (errr.. nula) experiencia con gvSIG:
>
>
>
>> 2009/3/26 Juan Guillermo Jordán Aldasoro :
>>
>>
> (...)
>
>
>>> Para gvSIG lo mejor sería partir del fichero CSV. Hay una forma de 
>>> importar
>>> ficheros CSV a shapefile.
>>>
>>> Crear una nueva tabla (tabla->nuevo->csv string). El CSV debe estar 
>>> separado
>>> por ";" en lugar de "," o no funcionará :-( . Puedes cambiar esto 
>>> fácilmente
>>> con un editor de texto.
>>>
>>>
>> El CSV del Kismet ya los trae así, así que ni siquiera tengo que
>> reemplazarlos :)
>>
>>
>>
>>> Crear una nueva vista. Menu vista->añadir capa de eventos.
>>> En el dialogo seleccionar la tabla (si es que has abierto más de una) y 
>>> los
>>> campos que constituyen latitud y longitud en tu tabla.
>>> Ya tienes la capa shapefile.
>>>
>>>
>>>
> Esto ya lo tengo :)
>
>
>
>>>     * Otros XMLs con esta información agrupada de diferentes formas,
>>> pero creo que los más interesantes son los anteriores.
>>>
>>>
>>>
>>> Haces el geoproceso correspondiente, por ejemplo un buffer.
>>>
>>>
>>> Esta parte es donde estoy más verde.  Pensaba que un "geoproceso" era
>>> un proceso (como un script) para "procesar" (valga la redundancia)
>>> datos georreferenciados.  Pero al decir lo del "buffer" me he perdido,
>>> y creo que estoy entendiéndolo mal.  Por otra parte, no tengo ni idea
>>> de cómo hacer un geoproceso, así que tengo aprender :P  ¿los
>>> geoprocesos son específicos de cada SIG? ¿Cómo has hecho el que envías
>>> en el correo?
>>>  Agradezco cualquier ayuda :)
>>>
>>>
>>>
>>> En gvSIG se haría de la siguiente manera (pasos aproximados, para más
>>> detalles ver manual):
>>>
>>> Con la capa shape seleccionada, pulsar menu de geoprocesos (un boton en 
>>> la
>>> barra de herramientas, o el menu vista->gestor de geoprocesos).
>>> Te aparece una lista de geoprocesos. Selecciona uno de los primeros, se
>>> llama buffer o área de influencia. Este geoproceso "engorda" las 
>>> geometrías,
>>> si es un punto crea un círculo, si es una línea un churrito :-P
>>> Aparece un diálogo. Hay varias opciones, puedes escoger un tamaño fijo 
>>> para
>>> el buffer, o sea, el radio de los círculos, porque en este caso tus
>>> geometrías serán puntos. También puedes seleccionar un campo de tu 
>>> shapefile
>>> para que cada círculo tenga un radio. En la prueba que hice para enviar 
>>> el
>>> dibujo fije yo manualmente un radio para cada círculo. El problema es 
>>> que
>>> siempre toma el valor como metros, creo. O sea que si tú tienes 
>>> decibelios
>>> es posible que te pinte círculos muy grandes, y no conozco la forma de 
>>>

Re: [Talk-es] Mapas de cobertura sobre OpenStreetMap

[Juan Guillermo Jordán Aldasoro]

Me alegro de que lo hayas solucionado.

Y ya en otro orden de cosas, si los datos de redes capturadas no son 
privados, considera la opción de subirlas a la base de datos de wigle 
[1] de puntos de acceso. No tienen una licencia tan "guay" como la de 
osm -al parecer no puedes hacer uso comercial de los datos-, pero tienes 
acceso a muchos datos para uso experimental. Yo estuve subiendo varios 
miles de puntos de acceso de Valencia.

Saludos
Juangui

[1] http://www.wigle.net/
[2] http://www.wigle.net/eula.html

Jonas Andradas escribió:
> Buenas...
>
> esto... xD sí era la proyección.  Ahora ya se ve bien, y las
> distancias son de 200 y 300 metros :)
>
> ¡¡Muchas gracias!!
>
> 2009/3/31 Jonas Andradas :
>   
>> Buenas,
>>
>> 2009/3/31 Juan Guillermo Jordán Aldasoro :
>> 
>>> En mi ejemplo yo usaba EPSG 4623. Los alcances que yo usaba eran del
>>> orden de 5-25 'unidades'. Digo unidades porque no tengo claro qué
>>> representan, en mi caso sí que parecía corresponderse a metros.
>>>   
>> Con todos los puntos pintados, cojo la herramienta de distancia y, de
>> una esquina de los puntos a la contraria, mide 0,01... Me temo que mi
>> problema va a estar ahí.  Pero no sé qué he hecho mal :(  Adjunto un
>> pantallazo.
>>
>> Voy a probar a cambiar la proyección, pero no creo que sea eso...
>>
>> 
>>> Jonas Andradas escribió:
>>>   
 Buenas de nuevo,

 me estoy encontrando con alguna dificultad, supongo que de mi poca
 (errr.. nula) experiencia con gvSIG:


 
> 2009/3/26 Juan Guillermo Jordán Aldasoro :
>
>   
 (...)

 
>> Para gvSIG lo mejor sería partir del fichero CSV. Hay una forma de 
>> importar
>> ficheros CSV a shapefile.
>>
>> Crear una nueva tabla (tabla->nuevo->csv string). El CSV debe estar 
>> separado
>> por ";" en lugar de "," o no funcionará :-( . Puedes cambiar esto 
>> fácilmente
>> con un editor de texto.
>>
>> 
> El CSV del Kismet ya los trae así, así que ni siquiera tengo que
> reemplazarlos :)
>
>
>   
>> Crear una nueva vista. Menu vista->añadir capa de eventos.
>> En el dialogo seleccionar la tabla (si es que has abierto más de una) y 
>> los
>> campos que constituyen latitud y longitud en tu tabla.
>> Ya tienes la capa shapefile.
>>
>>
>> 
 Esto ya lo tengo :)


 
>> * Otros XMLs con esta información agrupada de diferentes formas,
>> pero creo que los más interesantes son los anteriores.
>>
>>
>>
>> Haces el geoproceso correspondiente, por ejemplo un buffer.
>>
>>
>> Esta parte es donde estoy más verde.  Pensaba que un "geoproceso" era
>> un proceso (como un script) para "procesar" (valga la redundancia)
>> datos georreferenciados.  Pero al decir lo del "buffer" me he perdido,
>> y creo que estoy entendiéndolo mal.  Por otra parte, no tengo ni idea
>> de cómo hacer un geoproceso, así que tengo aprender :P  ¿los
>> geoprocesos son específicos de cada SIG? ¿Cómo has hecho el que envías
>> en el correo?
>>  Agradezco cualquier ayuda :)
>>
>>
>>
>> En gvSIG se haría de la siguiente manera (pasos aproximados, para más
>> detalles ver manual):
>>
>> Con la capa shape seleccionada, pulsar menu de geoprocesos (un boton en 
>> la
>> barra de herramientas, o el menu vista->gestor de geoprocesos).
>> Te aparece una lista de geoprocesos. Selecciona uno de los primeros, se
>> llama buffer o área de influencia. Este geoproceso "engorda" las 
>> geometrías,
>> si es un punto crea un círculo, si es una línea un churrito :-P
>> Aparece un diálogo. Hay varias opciones, puedes escoger un tamaño fijo 
>> para
>> el buffer, o sea, el radio de los círculos, porque en este caso tus
>> geometrías serán puntos. También puedes seleccionar un campo de tu 
>> shapefile
>> para que cada círculo tenga un radio. En la prueba que hice para enviar 
>> el
>> dibujo fije yo manualmente un radio para cada círculo. El problema es que
>> siempre toma el valor como metros, creo. O sea que si tú tienes 
>> decibelios
>> es posible que te pinte círculos muy grandes, y no conozco la forma de 
>> hacer
>> que cambie la proporción (Quizás podrías modificar el CSV con excel para
>> tener una columna cuyo valor sea decibelios/algo).
>>
>> 
 Aquí es donde viene mi problema.  Como alcance, tenía un número
 decimal bastante "largo", del estilo de "30.45712393734458".  Al
 intentar seleccionar el campo "Cobertura" para el radio de los
 círculos, obtengo un mensaje de error que dice que no es un campo
 numérico.  He cambiado el script en Perl con el que hago el CSV para
 que me redondee este número a dos dígitos decimales, y sigo obteniendo
 el mismo error.  Sin embargo, si indic

Re: [Talk-es] Mapas de cobertura sobre OpenStreetMap

[Carlos Dávila]

Jonas Andradas escribió:
> Buenas de nuevo,
>
> me estoy encontrando con alguna dificultad, supongo que de mi poca
> (errr.. nula) experiencia con gvSIG:
>
>   
>> 2009/3/26 Juan Guillermo Jordán Aldasoro :
>> 
> (...)
>   
>>> Para gvSIG lo mejor sería partir del fichero CSV. Hay una forma de importar
>>> ficheros CSV a shapefile.
>>>
>>> Crear una nueva tabla (tabla->nuevo->csv string). El CSV debe estar separado
>>> por ";" en lugar de "," o no funcionará :-( . Puedes cambiar esto fácilmente
>>> con un editor de texto.
>>>   
>> El CSV del Kismet ya los trae así, así que ni siquiera tengo que
>> reemplazarlos :)
>>
>> 
>>> Crear una nueva vista. Menu vista->añadir capa de eventos.
>>> En el dialogo seleccionar la tabla (si es que has abierto más de una) y los
>>> campos que constituyen latitud y longitud en tu tabla.
>>> Ya tienes la capa shapefile.
>>>
>>>   
>
> Esto ya lo tengo :)
>
>   
>>> * Otros XMLs con esta información agrupada de diferentes formas,
>>> pero creo que los más interesantes son los anteriores.
>>>
>>>
>>>
>>> Haces el geoproceso correspondiente, por ejemplo un buffer.
>>>
>>>
>>> Esta parte es donde estoy más verde.  Pensaba que un "geoproceso" era
>>> un proceso (como un script) para "procesar" (valga la redundancia)
>>> datos georreferenciados.  Pero al decir lo del "buffer" me he perdido,
>>> y creo que estoy entendiéndolo mal.  Por otra parte, no tengo ni idea
>>> de cómo hacer un geoproceso, así que tengo aprender :P  ¿los
>>> geoprocesos son específicos de cada SIG? ¿Cómo has hecho el que envías
>>> en el correo?
>>>  Agradezco cualquier ayuda :)
>>>
>>>
>>>
>>> En gvSIG se haría de la siguiente manera (pasos aproximados, para más
>>> detalles ver manual):
>>>
>>> Con la capa shape seleccionada, pulsar menu de geoprocesos (un boton en la
>>> barra de herramientas, o el menu vista->gestor de geoprocesos).
>>> Te aparece una lista de geoprocesos. Selecciona uno de los primeros, se
>>> llama buffer o área de influencia. Este geoproceso "engorda" las geometrías,
>>> si es un punto crea un círculo, si es una línea un churrito :-P
>>> Aparece un diálogo. Hay varias opciones, puedes escoger un tamaño fijo para
>>> el buffer, o sea, el radio de los círculos, porque en este caso tus
>>> geometrías serán puntos. También puedes seleccionar un campo de tu shapefile
>>> para que cada círculo tenga un radio. En la prueba que hice para enviar el
>>> dibujo fije yo manualmente un radio para cada círculo. El problema es que
>>> siempre toma el valor como metros, creo. O sea que si tú tienes decibelios
>>> es posible que te pinte círculos muy grandes, y no conozco la forma de hacer
>>> que cambie la proporción (Quizás podrías modificar el CSV con excel para
>>> tener una columna cuyo valor sea decibelios/algo).
>>>   
>
> Aquí es donde viene mi problema.  Como alcance, tenía un número
> decimal bastante "largo", del estilo de "30.45712393734458".  Al
> intentar seleccionar el campo "Cobertura" para el radio de los
> círculos, obtengo un mensaje de error que dice que no es un campo
> numérico.  He cambiado el script en Perl con el que hago el CSV para
> que me redondee este número a dos dígitos decimales, y sigo obteniendo
> el mismo error.  Sin embargo, si indico yo a mano un radio, se come
> toda la imagen incluso poniendo como radio "1".  O bien no estoy
> importando la capa de latitud y longitud bien, o el radio no son
> metros, o yo no lo he entendido :)  Si pongo como radio "0.00150", al
> menos veo círculos y zonas blancas, pero creo que siguen siendo
> demasiado grandes.  ¿Alguien sabe qué puedo estar haciendo mal?  Voy a
> intentar añadir una capa de WMS para ver si veo realmente dónde me
> estoy equivocando.  ¿Por qué un radio de "30.23" del campo "Cobertura"
> (alcance, realmente) no lo coge?  ¿Puede tener que ver que esté usando
> EPSG 23030?
>   
Revisa la definición de los campos de la tabla (el .dbf). En ocasiones
me ha pasado algo parecido y era porque el campo en cuestión estaba
definido como string, no como numérico.
>   
>> (...)
>> 
>>> Puedes decir si quieres que los círculos se fusionen, y si quieres tener
>>> varios anillos en cada círculo. Para hacerlo más bonito, vamos.
>>>   
>> Haré ambas cosas:  Cuando son diferentes redes (con diferente ESSID),
>> no los fusionaré, pero cuando sea la cobertura de una red con muchos
>> APs, sí haré lo de la fusión.
>>
>> 
>>> Luego te pide que escojas un nuevo fichero shape para crear el buffer.
>>> Aceptar y te generará una nueva capa. A esa capa le puedes cambiar la
>>> simbología para que tenga transparencia y deje ver lo que hay debajo.
>>>
>>>   
>> Eso también me gustaba de tu ejemplo, porque en el gpsmap, la
>> transparencia es de cada círculo.  Cuando se superponen varios, se
>> hacen cada vez más opacos, y terminan por tapar el mapa que hay
>> debajo, y sólo se ven manchurrones de color.
>>
>> 
>>> Quizás con la extensión de Sextante tienes más opciones, que opinen los que
>>> la 

Re: [Talk-es] Mapas de cobertura sobre OpenStreetMap

[Jonas Andradas]

Buenas...

esto... xD sí era la proyección.  Ahora ya se ve bien, y las
distancias son de 200 y 300 metros :)

¡¡Muchas gracias!!

2009/3/31 Jonas Andradas :
> Buenas,
>
> 2009/3/31 Juan Guillermo Jordán Aldasoro :
>> En mi ejemplo yo usaba EPSG 4623. Los alcances que yo usaba eran del
>> orden de 5-25 'unidades'. Digo unidades porque no tengo claro qué
>> representan, en mi caso sí que parecía corresponderse a metros.
>
> Con todos los puntos pintados, cojo la herramienta de distancia y, de
> una esquina de los puntos a la contraria, mide 0,01... Me temo que mi
> problema va a estar ahí.  Pero no sé qué he hecho mal :(  Adjunto un
> pantallazo.
>
> Voy a probar a cambiar la proyección, pero no creo que sea eso...
>
>>
>> Jonas Andradas escribió:
>>> Buenas de nuevo,
>>>
>>> me estoy encontrando con alguna dificultad, supongo que de mi poca
>>> (errr.. nula) experiencia con gvSIG:
>>>
>>>
 2009/3/26 Juan Guillermo Jordán Aldasoro :

>>> (...)
>>>
> Para gvSIG lo mejor sería partir del fichero CSV. Hay una forma de 
> importar
> ficheros CSV a shapefile.
>
> Crear una nueva tabla (tabla->nuevo->csv string). El CSV debe estar 
> separado
> por ";" en lugar de "," o no funcionará :-( . Puedes cambiar esto 
> fácilmente
> con un editor de texto.
>
 El CSV del Kismet ya los trae así, así que ni siquiera tengo que
 reemplazarlos :)


> Crear una nueva vista. Menu vista->añadir capa de eventos.
> En el dialogo seleccionar la tabla (si es que has abierto más de una) y 
> los
> campos que constituyen latitud y longitud en tu tabla.
> Ya tienes la capa shapefile.
>
>
>>>
>>> Esto ya lo tengo :)
>>>
>>>
>     * Otros XMLs con esta información agrupada de diferentes formas,
> pero creo que los más interesantes son los anteriores.
>
>
>
> Haces el geoproceso correspondiente, por ejemplo un buffer.
>
>
> Esta parte es donde estoy más verde.  Pensaba que un "geoproceso" era
> un proceso (como un script) para "procesar" (valga la redundancia)
> datos georreferenciados.  Pero al decir lo del "buffer" me he perdido,
> y creo que estoy entendiéndolo mal.  Por otra parte, no tengo ni idea
> de cómo hacer un geoproceso, así que tengo aprender :P  ¿los
> geoprocesos son específicos de cada SIG? ¿Cómo has hecho el que envías
> en el correo?
>  Agradezco cualquier ayuda :)
>
>
>
> En gvSIG se haría de la siguiente manera (pasos aproximados, para más
> detalles ver manual):
>
> Con la capa shape seleccionada, pulsar menu de geoprocesos (un boton en la
> barra de herramientas, o el menu vista->gestor de geoprocesos).
> Te aparece una lista de geoprocesos. Selecciona uno de los primeros, se
> llama buffer o área de influencia. Este geoproceso "engorda" las 
> geometrías,
> si es un punto crea un círculo, si es una línea un churrito :-P
> Aparece un diálogo. Hay varias opciones, puedes escoger un tamaño fijo 
> para
> el buffer, o sea, el radio de los círculos, porque en este caso tus
> geometrías serán puntos. También puedes seleccionar un campo de tu 
> shapefile
> para que cada círculo tenga un radio. En la prueba que hice para enviar el
> dibujo fije yo manualmente un radio para cada círculo. El problema es que
> siempre toma el valor como metros, creo. O sea que si tú tienes decibelios
> es posible que te pinte círculos muy grandes, y no conozco la forma de 
> hacer
> que cambie la proporción (Quizás podrías modificar el CSV con excel para
> tener una columna cuyo valor sea decibelios/algo).
>
>>>
>>> Aquí es donde viene mi problema.  Como alcance, tenía un número
>>> decimal bastante "largo", del estilo de "30.45712393734458".  Al
>>> intentar seleccionar el campo "Cobertura" para el radio de los
>>> círculos, obtengo un mensaje de error que dice que no es un campo
>>> numérico.  He cambiado el script en Perl con el que hago el CSV para
>>> que me redondee este número a dos dígitos decimales, y sigo obteniendo
>>> el mismo error.  Sin embargo, si indico yo a mano un radio, se come
>>> toda la imagen incluso poniendo como radio "1".  O bien no estoy
>>> importando la capa de latitud y longitud bien, o el radio no son
>>> metros, o yo no lo he entendido :)  Si pongo como radio "0.00150", al
>>> menos veo círculos y zonas blancas, pero creo que siguen siendo
>>> demasiado grandes.  ¿Alguien sabe qué puedo estar haciendo mal?  Voy a
>>> intentar añadir una capa de WMS para ver si veo realmente dónde me
>>> estoy equivocando.  ¿Por qué un radio de "30.23" del campo "Cobertura"
>>> (alcance, realmente) no lo coge?  ¿Puede tener que ver que esté usando
>>> EPSG 23030?
>>>
>>>
 (...)

> Puedes decir si quieres que los círculos se fusionen, y si quieres tener
> varios anillos en cada círculo. Para hacerlo más bonito, vamos.
>
 Haré ambas cosas:  Cuando son difer

Re: [Talk-es] Mapas de cobertura sobre OpenStreetMap

[Jonas Andradas]

Buenas,

2009/3/31 Juan Guillermo Jordán Aldasoro :
> En mi ejemplo yo usaba EPSG 4623. Los alcances que yo usaba eran del
> orden de 5-25 'unidades'. Digo unidades porque no tengo claro qué
> representan, en mi caso sí que parecía corresponderse a metros.

Con todos los puntos pintados, cojo la herramienta de distancia y, de
una esquina de los puntos a la contraria, mide 0,01... Me temo que mi
problema va a estar ahí.  Pero no sé qué he hecho mal :(  Adjunto un
pantallazo.

Voy a probar a cambiar la proyección, pero no creo que sea eso...

>
> Jonas Andradas escribió:
>> Buenas de nuevo,
>>
>> me estoy encontrando con alguna dificultad, supongo que de mi poca
>> (errr.. nula) experiencia con gvSIG:
>>
>>
>>> 2009/3/26 Juan Guillermo Jordán Aldasoro :
>>>
>> (...)
>>
 Para gvSIG lo mejor sería partir del fichero CSV. Hay una forma de importar
 ficheros CSV a shapefile.

 Crear una nueva tabla (tabla->nuevo->csv string). El CSV debe estar 
 separado
 por ";" en lugar de "," o no funcionará :-( . Puedes cambiar esto 
 fácilmente
 con un editor de texto.

>>> El CSV del Kismet ya los trae así, así que ni siquiera tengo que
>>> reemplazarlos :)
>>>
>>>
 Crear una nueva vista. Menu vista->añadir capa de eventos.
 En el dialogo seleccionar la tabla (si es que has abierto más de una) y los
 campos que constituyen latitud y longitud en tu tabla.
 Ya tienes la capa shapefile.


>>
>> Esto ya lo tengo :)
>>
>>
     * Otros XMLs con esta información agrupada de diferentes formas,
 pero creo que los más interesantes son los anteriores.



 Haces el geoproceso correspondiente, por ejemplo un buffer.


 Esta parte es donde estoy más verde.  Pensaba que un "geoproceso" era
 un proceso (como un script) para "procesar" (valga la redundancia)
 datos georreferenciados.  Pero al decir lo del "buffer" me he perdido,
 y creo que estoy entendiéndolo mal.  Por otra parte, no tengo ni idea
 de cómo hacer un geoproceso, así que tengo aprender :P  ¿los
 geoprocesos son específicos de cada SIG? ¿Cómo has hecho el que envías
 en el correo?
  Agradezco cualquier ayuda :)



 En gvSIG se haría de la siguiente manera (pasos aproximados, para más
 detalles ver manual):

 Con la capa shape seleccionada, pulsar menu de geoprocesos (un boton en la
 barra de herramientas, o el menu vista->gestor de geoprocesos).
 Te aparece una lista de geoprocesos. Selecciona uno de los primeros, se
 llama buffer o área de influencia. Este geoproceso "engorda" las 
 geometrías,
 si es un punto crea un círculo, si es una línea un churrito :-P
 Aparece un diálogo. Hay varias opciones, puedes escoger un tamaño fijo para
 el buffer, o sea, el radio de los círculos, porque en este caso tus
 geometrías serán puntos. También puedes seleccionar un campo de tu 
 shapefile
 para que cada círculo tenga un radio. En la prueba que hice para enviar el
 dibujo fije yo manualmente un radio para cada círculo. El problema es que
 siempre toma el valor como metros, creo. O sea que si tú tienes decibelios
 es posible que te pinte círculos muy grandes, y no conozco la forma de 
 hacer
 que cambie la proporción (Quizás podrías modificar el CSV con excel para
 tener una columna cuyo valor sea decibelios/algo).

>>
>> Aquí es donde viene mi problema.  Como alcance, tenía un número
>> decimal bastante "largo", del estilo de "30.45712393734458".  Al
>> intentar seleccionar el campo "Cobertura" para el radio de los
>> círculos, obtengo un mensaje de error que dice que no es un campo
>> numérico.  He cambiado el script en Perl con el que hago el CSV para
>> que me redondee este número a dos dígitos decimales, y sigo obteniendo
>> el mismo error.  Sin embargo, si indico yo a mano un radio, se come
>> toda la imagen incluso poniendo como radio "1".  O bien no estoy
>> importando la capa de latitud y longitud bien, o el radio no son
>> metros, o yo no lo he entendido :)  Si pongo como radio "0.00150", al
>> menos veo círculos y zonas blancas, pero creo que siguen siendo
>> demasiado grandes.  ¿Alguien sabe qué puedo estar haciendo mal?  Voy a
>> intentar añadir una capa de WMS para ver si veo realmente dónde me
>> estoy equivocando.  ¿Por qué un radio de "30.23" del campo "Cobertura"
>> (alcance, realmente) no lo coge?  ¿Puede tener que ver que esté usando
>> EPSG 23030?
>>
>>
>>> (...)
>>>
 Puedes decir si quieres que los círculos se fusionen, y si quieres tener
 varios anillos en cada círculo. Para hacerlo más bonito, vamos.

>>> Haré ambas cosas:  Cuando son diferentes redes (con diferente ESSID),
>>> no los fusionaré, pero cuando sea la cobertura de una red con muchos
>>> APs, sí haré lo de la fusión.
>>>
>>>
 Luego te pide que escojas un nuevo fichero shape para crear el buffer.
 Aceptar y te generará una nueva capa. A esa capa le puedes cambiar la

Re: [Talk-es] Plugin de cálculo de rutas para JOSM

[Iván Sánchez Ortega]

El Martes, 31 de Marzo de 2009, Juan Guillermo Jordán Aldasoro escribió:
>  Buenas. Hemos desarrollado un plugin de cálculo de rutas [1] para JOSM. Se
> llama routing y está disponible para las últimas revisiones de JOSM.

Lo acabo de probar y... ¡Mola!

Ahora bien, sugerencia...:

- Además de los tres botones que se crean en la barra de herramientas lateral, 
se crea un nuevo "pane" que va debajo de los tags y el validador (que se 
activa/desactiva con otro botón). Por temas de consistencia de interfaz, yo 
movería los tres botones de crear/borrar/mover punto de ruta a ese "pane". Y 
dejar la capa siempre visible.
Básicamente sería copiar cómo se comporta a nivel de GUI el plugin validador.


... Y wishlist:

- Integración con el plugin LiveGPS: hacer que el inicio de la ruta sea la 
posición actual (y recalcularla cada X tiempo).

- Integración con el plugin validador + implementación de Travelling Salesman 
**Y** cartero chino a la vez: Poner *todos* los nodos y ways con errores como 
destinos.

Estos dos últimos le darían un vuelco a las mapping parties para corregir 
errores que no veas :-D


Por cierto, ¿tenéis pensado anunciar esto en osm-dev o osm-talk?

-- 
--
Iván Sánchez Ortega 

Todos los hijos de puta son hijos de puta, pero algunos hijos de puta 
son "hijos de puta".
  -- Terry Pratchett, El País del Fin del Mundo.".


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] estadísticas OSM en España actualiza das

[Juan Lucas Dominguez Rubio]

Hola, pues... es que las mini-roundabout son tan rematadamente feas que las he 
ido borrando poco a poco.
 
Es broma!! Es broma!!
(aunque lo he pensado más de una vez, eh?)
:-D
 
Salu2



De: talk-es-boun...@openstreetmap.org en nombre de Miguel Blanco
Enviado el: mar 31/03/2009 14:54
Para: ce...@mitago.net; Discusión en Español de OpenStreetMap
Asunto: Re: [Talk-es]estadísticas OSM en España actualizadas



Lo de las "road" lo puedo extraer para la próxima vez, no es mucho problema

También parece que han "casi desaparecido" los "toll_booth" ¿?

Si recupero la información ¿se la curraría alguien para subirla y
"enlazarla" correctamente
(descartando duplicados, etc)? Son unas 850 rotondas  desde julio.

Saludos,

El día 31 de marzo de 2009 12:46, Celso González  escribió:
> On Tue, Mar 31, 2009 at 12:15:49PM +0200, Miguel Blanco wrote:
>> Hola a todos/as,
>>
>> no están todos los tipos de vías ni todos los tipos de POIs, pero ahí van:
>>
>> http://www.terra.es/personal4/miblma/
>
> ¿Cómo es que las roundabout van decreciendo?
> Es un dato que no me cuadra
>
> Aparte en los tipos de vía no se si convendría incluir también las road, yo 
> las uso
> mucho para marcar recorridos que he hecho pero que me faltan por etiquetar 
> correctamente.
>
> --
> Celso González (PerroVerd)
> http://mitago.net  
>
> ___
> 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 mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] estadísticas OSM en España actualiza das

[Miguel Blanco]

Lo de las "road" lo puedo extraer para la próxima vez, no es mucho problema

También parece que han "casi desaparecido" los "toll_booth" ¿?

Si recupero la información ¿se la curraría alguien para subirla y
"enlazarla" correctamente
(descartando duplicados, etc)? Son unas 850 rotondas  desde julio.

Saludos,

El día 31 de marzo de 2009 12:46, Celso González  escribió:
> On Tue, Mar 31, 2009 at 12:15:49PM +0200, Miguel Blanco wrote:
>> Hola a todos/as,
>>
>> no están todos los tipos de vías ni todos los tipos de POIs, pero ahí van:
>>
>> http://www.terra.es/personal4/miblma/
>
> ¿Cómo es que las roundabout van decreciendo?
> Es un dato que no me cuadra
>
> Aparte en los tipos de vía no se si convendría incluir también las road, yo 
> las uso
> mucho para marcar recorridos que he hecho pero que me faltan por etiquetar 
> correctamente.
>
> --
> Celso González (PerroVerd)
> http://mitago.net
>
> ___
> 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] estadísticas OSM en España actualiza das

[sergio sevillano]

Celso González escribió:

On Tue, Mar 31, 2009 at 12:15:49PM +0200, Miguel Blanco wrote:
  

Hola a todos/as,

no están todos los tipos de vías ni todos los tipos de POIs, pero ahí van:

http://www.terra.es/personal4/miblma/



¿Cómo es que las roundabout van decreciendo?
Es un dato que no me cuadra

Aparte en los tipos de vía no se si convendría incluir también las road, yo las 
uso
mucho para marcar recorridos que he hecho pero que me faltan por etiquetar 
correctamente.

  

mmmsi
será aquello que detectó Pablo
http://lists.openstreetmap.org/pipermail/talk-es/2009-March/002757.html

alguien chequeó el historial de objetos desaparecidos. yo no sé como se 
hace.

lo mismo hay un patrón.
a mí me dá que es un bot de esos

sergio
___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Mapas de cobertura sobre OpenStreetMap

[Juan Guillermo Jordán Aldasoro]

En mi ejemplo yo usaba EPSG 4623. Los alcances que yo usaba eran del 
orden de 5-25 'unidades'. Digo unidades porque no tengo claro qué 
representan, en mi caso sí que parecía corresponderse a metros.

Jonas Andradas escribió:
> Buenas de nuevo,
>
> me estoy encontrando con alguna dificultad, supongo que de mi poca
> (errr.. nula) experiencia con gvSIG:
>
>   
>> 2009/3/26 Juan Guillermo Jordán Aldasoro :
>> 
> (...)
>   
>>> Para gvSIG lo mejor sería partir del fichero CSV. Hay una forma de importar
>>> ficheros CSV a shapefile.
>>>
>>> Crear una nueva tabla (tabla->nuevo->csv string). El CSV debe estar separado
>>> por ";" en lugar de "," o no funcionará :-( . Puedes cambiar esto fácilmente
>>> con un editor de texto.
>>>   
>> El CSV del Kismet ya los trae así, así que ni siquiera tengo que
>> reemplazarlos :)
>>
>> 
>>> Crear una nueva vista. Menu vista->añadir capa de eventos.
>>> En el dialogo seleccionar la tabla (si es que has abierto más de una) y los
>>> campos que constituyen latitud y longitud en tu tabla.
>>> Ya tienes la capa shapefile.
>>>
>>>   
>
> Esto ya lo tengo :)
>
>   
>>> * Otros XMLs con esta información agrupada de diferentes formas,
>>> pero creo que los más interesantes son los anteriores.
>>>
>>>
>>>
>>> Haces el geoproceso correspondiente, por ejemplo un buffer.
>>>
>>>
>>> Esta parte es donde estoy más verde.  Pensaba que un "geoproceso" era
>>> un proceso (como un script) para "procesar" (valga la redundancia)
>>> datos georreferenciados.  Pero al decir lo del "buffer" me he perdido,
>>> y creo que estoy entendiéndolo mal.  Por otra parte, no tengo ni idea
>>> de cómo hacer un geoproceso, así que tengo aprender :P  ¿los
>>> geoprocesos son específicos de cada SIG? ¿Cómo has hecho el que envías
>>> en el correo?
>>>  Agradezco cualquier ayuda :)
>>>
>>>
>>>
>>> En gvSIG se haría de la siguiente manera (pasos aproximados, para más
>>> detalles ver manual):
>>>
>>> Con la capa shape seleccionada, pulsar menu de geoprocesos (un boton en la
>>> barra de herramientas, o el menu vista->gestor de geoprocesos).
>>> Te aparece una lista de geoprocesos. Selecciona uno de los primeros, se
>>> llama buffer o área de influencia. Este geoproceso "engorda" las geometrías,
>>> si es un punto crea un círculo, si es una línea un churrito :-P
>>> Aparece un diálogo. Hay varias opciones, puedes escoger un tamaño fijo para
>>> el buffer, o sea, el radio de los círculos, porque en este caso tus
>>> geometrías serán puntos. También puedes seleccionar un campo de tu shapefile
>>> para que cada círculo tenga un radio. En la prueba que hice para enviar el
>>> dibujo fije yo manualmente un radio para cada círculo. El problema es que
>>> siempre toma el valor como metros, creo. O sea que si tú tienes decibelios
>>> es posible que te pinte círculos muy grandes, y no conozco la forma de hacer
>>> que cambie la proporción (Quizás podrías modificar el CSV con excel para
>>> tener una columna cuyo valor sea decibelios/algo).
>>>   
>
> Aquí es donde viene mi problema.  Como alcance, tenía un número
> decimal bastante "largo", del estilo de "30.45712393734458".  Al
> intentar seleccionar el campo "Cobertura" para el radio de los
> círculos, obtengo un mensaje de error que dice que no es un campo
> numérico.  He cambiado el script en Perl con el que hago el CSV para
> que me redondee este número a dos dígitos decimales, y sigo obteniendo
> el mismo error.  Sin embargo, si indico yo a mano un radio, se come
> toda la imagen incluso poniendo como radio "1".  O bien no estoy
> importando la capa de latitud y longitud bien, o el radio no son
> metros, o yo no lo he entendido :)  Si pongo como radio "0.00150", al
> menos veo círculos y zonas blancas, pero creo que siguen siendo
> demasiado grandes.  ¿Alguien sabe qué puedo estar haciendo mal?  Voy a
> intentar añadir una capa de WMS para ver si veo realmente dónde me
> estoy equivocando.  ¿Por qué un radio de "30.23" del campo "Cobertura"
> (alcance, realmente) no lo coge?  ¿Puede tener que ver que esté usando
> EPSG 23030?
>
>   
>> (...)
>> 
>>> Puedes decir si quieres que los círculos se fusionen, y si quieres tener
>>> varios anillos en cada círculo. Para hacerlo más bonito, vamos.
>>>   
>> Haré ambas cosas:  Cuando son diferentes redes (con diferente ESSID),
>> no los fusionaré, pero cuando sea la cobertura de una red con muchos
>> APs, sí haré lo de la fusión.
>>
>> 
>>> Luego te pide que escojas un nuevo fichero shape para crear el buffer.
>>> Aceptar y te generará una nueva capa. A esa capa le puedes cambiar la
>>> simbología para que tenga transparencia y deje ver lo que hay debajo.
>>>
>>>   
>> Eso también me gustaba de tu ejemplo, porque en el gpsmap, la
>> transparencia es de cada círculo.  Cuando se superponen varios, se
>> hacen cada vez más opacos, y terminan por tapar el mapa que hay
>> debajo, y sólo se ven manchurrones de color.
>>
>> 
>>> Quizás con la extensión de Sextante tienes más opciones, que op

Re: [Talk-es] estadísticas OSM en España actualiz adas

[Xavier Barnada]

> Guau!! Qué fino! Dentro de poco veremos a la ministra de Fomento
> presumiendo de cuántos km de carreteras hay en OSM ;-)
>
> Juan Lucas
No lo creo, si tubieran interes por estas cosas ya habrian creado ellos mismos 
los planos que lo tienen mucho mas facil.Aunque realmente es lo que deberian 
hacer

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] estadísticas OSM en España actualiza das

[Celso González]

On Tue, Mar 31, 2009 at 12:15:49PM +0200, Miguel Blanco wrote:
> Hola a todos/as,
> 
> no están todos los tipos de vías ni todos los tipos de POIs, pero ahí van:
> 
> http://www.terra.es/personal4/miblma/

¿Cómo es que las roundabout van decreciendo?
Es un dato que no me cuadra

Aparte en los tipos de vía no se si convendría incluir también las road, yo las 
uso
mucho para marcar recorridos que he hecho pero que me faltan por etiquetar 
correctamente.

-- 
Celso González (PerroVerd)
http://mitago.net

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Plugin de cálculo de rutas para JOSM

[Juan Lucas Dominguez Rubio]

Yo no lo he probado aún (estoy un poco enfadado con JOSM últimamente) pero me 
uno al entusiasmo!! :-D
 
Saludos,
Juan Lucas
 


De: talk-es-boun...@openstreetmap.org en nombre de sergio sevillano
Enviado el: mar 31/03/2009 11:37
Para: Discusión en Español de OpenStreetMap
Asunto: Re: [Talk-es] Plugin de cálculo de rutas para JOSM



perdón, si funciona.
es el JOSM lo que tengo que actualizar
con la versión 1515 ok

___
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] estadísticas OSM en España actualiza das

[Juan Lucas Dominguez Rubio]

Guau!! Qué fino! Dentro de poco veremos a la ministra de Fomento presumiendo de 
cuántos km de carreteras hay en OSM ;-)
 
Juan Lucas
 


De: talk-es-boun...@openstreetmap.org en nombre de Miguel Blanco
Enviado el: mar 31/03/2009 12:15
Para: Discusión en Español de OpenStreetMap
Asunto: [Talk-es] estadísticas OSM en España actualizadas



Hola a todos/as,

no están todos los tipos de vías ni todos los tipos de POIs, pero ahí van:

http://www.terra.es/personal4/miblma/


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

[Talk-es] estadísticas OSM en España actualiza das

[Miguel Blanco]

Hola a todos/as,

no están todos los tipos de vías ni todos los tipos de POIs, pero ahí van:

http://www.terra.es/personal4/miblma/


Saludos,

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Mapas de cobertura sobre OpenStreetMap

[Jonas Andradas]

Buenas de nuevo,

me estoy encontrando con alguna dificultad, supongo que de mi poca
(errr.. nula) experiencia con gvSIG:

> 2009/3/26 Juan Guillermo Jordán Aldasoro :
(...)
>>
>>
>> Para gvSIG lo mejor sería partir del fichero CSV. Hay una forma de importar
>> ficheros CSV a shapefile.
>>
>> Crear una nueva tabla (tabla->nuevo->csv string). El CSV debe estar separado
>> por ";" en lugar de "," o no funcionará :-( . Puedes cambiar esto fácilmente
>> con un editor de texto.
>
> El CSV del Kismet ya los trae así, así que ni siquiera tengo que
> reemplazarlos :)
>
>> Crear una nueva vista. Menu vista->añadir capa de eventos.
>> En el dialogo seleccionar la tabla (si es que has abierto más de una) y los
>> campos que constituyen latitud y longitud en tu tabla.
>> Ya tienes la capa shapefile.
>>

Esto ya lo tengo :)

>>     * Otros XMLs con esta información agrupada de diferentes formas,
>> pero creo que los más interesantes son los anteriores.
>>
>>
>>
>> Haces el geoproceso correspondiente, por ejemplo un buffer.
>>
>>
>> Esta parte es donde estoy más verde.  Pensaba que un "geoproceso" era
>> un proceso (como un script) para "procesar" (valga la redundancia)
>> datos georreferenciados.  Pero al decir lo del "buffer" me he perdido,
>> y creo que estoy entendiéndolo mal.  Por otra parte, no tengo ni idea
>> de cómo hacer un geoproceso, así que tengo aprender :P  ¿los
>> geoprocesos son específicos de cada SIG? ¿Cómo has hecho el que envías
>> en el correo?
>>  Agradezco cualquier ayuda :)
>>
>>
>>
>> En gvSIG se haría de la siguiente manera (pasos aproximados, para más
>> detalles ver manual):
>>
>> Con la capa shape seleccionada, pulsar menu de geoprocesos (un boton en la
>> barra de herramientas, o el menu vista->gestor de geoprocesos).
>> Te aparece una lista de geoprocesos. Selecciona uno de los primeros, se
>> llama buffer o área de influencia. Este geoproceso "engorda" las geometrías,
>> si es un punto crea un círculo, si es una línea un churrito :-P
>> Aparece un diálogo. Hay varias opciones, puedes escoger un tamaño fijo para
>> el buffer, o sea, el radio de los círculos, porque en este caso tus
>> geometrías serán puntos. También puedes seleccionar un campo de tu shapefile
>> para que cada círculo tenga un radio. En la prueba que hice para enviar el
>> dibujo fije yo manualmente un radio para cada círculo. El problema es que
>> siempre toma el valor como metros, creo. O sea que si tú tienes decibelios
>> es posible que te pinte círculos muy grandes, y no conozco la forma de hacer
>> que cambie la proporción (Quizás podrías modificar el CSV con excel para
>> tener una columna cuyo valor sea decibelios/algo).

Aquí es donde viene mi problema.  Como alcance, tenía un número
decimal bastante "largo", del estilo de "30.45712393734458".  Al
intentar seleccionar el campo "Cobertura" para el radio de los
círculos, obtengo un mensaje de error que dice que no es un campo
numérico.  He cambiado el script en Perl con el que hago el CSV para
que me redondee este número a dos dígitos decimales, y sigo obteniendo
el mismo error.  Sin embargo, si indico yo a mano un radio, se come
toda la imagen incluso poniendo como radio "1".  O bien no estoy
importando la capa de latitud y longitud bien, o el radio no son
metros, o yo no lo he entendido :)  Si pongo como radio "0.00150", al
menos veo círculos y zonas blancas, pero creo que siguen siendo
demasiado grandes.  ¿Alguien sabe qué puedo estar haciendo mal?  Voy a
intentar añadir una capa de WMS para ver si veo realmente dónde me
estoy equivocando.  ¿Por qué un radio de "30.23" del campo "Cobertura"
(alcance, realmente) no lo coge?  ¿Puede tener que ver que esté usando
EPSG 23030?

>
>(...)
>> Puedes decir si quieres que los círculos se fusionen, y si quieres tener
>> varios anillos en cada círculo. Para hacerlo más bonito, vamos.
>
> Haré ambas cosas:  Cuando son diferentes redes (con diferente ESSID),
> no los fusionaré, pero cuando sea la cobertura de una red con muchos
> APs, sí haré lo de la fusión.
>
>> Luego te pide que escojas un nuevo fichero shape para crear el buffer.
>> Aceptar y te generará una nueva capa. A esa capa le puedes cambiar la
>> simbología para que tenga transparencia y deje ver lo que hay debajo.
>>
>
> Eso también me gustaba de tu ejemplo, porque en el gpsmap, la
> transparencia es de cada círculo.  Cuando se superponen varios, se
> hacen cada vez más opacos, y terminan por tapar el mapa que hay
> debajo, y sólo se ven manchurrones de color.
>
>> Quizás con la extensión de Sextante tienes más opciones, que opinen los que
>> la conozcan.
>>
>> A jugar!
>>
>> Juangui
>>

Muchas gracias por todo de nuevo,

-- 
Jonás Andradas

Skype: jontux
LinkedIn: http://www.linkedin.com/in/andradas
GPG Fingerprint:  5A90 3319 48BC E0DC 17D9
   130B B5E2 9AFD 7649 30D5
Keyservers:  wwwkeys.eu.pgp.net | pgp.rediris.es

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.o

Re: [Talk-es] Plugin de cálculo de rutas para JOSM

[sergio sevillano]

perdón, si funciona.
es el JOSM lo que tengo que actualizar
con la versión 1515 ok

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Plugin de cálculo de rutas para JOSM

[sergio sevillano]

mmm, no funciona!

me sale en la lista de complementos
lo descargo
reinicio
al iniciar me advierte que necesito actualizar el complemento routing
en preferencias le doy a actualizar
me dice que ya está actualizado

no me aparece un nuevo menú

cada vez que arranco JOSM me sigue advirtiendo que tengo que acualizar...

estoy en win xp
JOSM versión 1504

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Plugin de cálculo de rutas para JOSM

[sergio sevillano]

Juan Guillermo Jordán Aldasoro escribió:
> sergio sevillano escribió:
>   
>> Pedro-Juan Ferrer Matoses escribió:
>>   
>> 
>>> ¡Excelente noticia!
>>>
>>> ¡Enhorabuena!
>>>
>>>   
>>> 
>>>   
>> muy bien!
>>
>> a ver si algún día vemos un plugin para el cálculo del "problema del 
>> cartero chino"...
>>
>>   
>> 
> Supongo que te refieres al traveling salesman. 
no, es distinto.
el "traveling salesman problem" es para reparto pasando por varios 
puntos. (ej. [ mensajero] camino mas corto para pasar por Burgos, 
Almería, Barcelona y Cuenca. ).
el "chinese postman problem" es para reparto recorriendo todos los 
segmentos de un área ( ej. [ cartero ] camino mas corto para repartir 
las cartas a todos los números de las calles de un barrio. ).

pero claro es mucho más complejo.

De todas formas gracias por vuestro plugin
ahora mismo me lo instalo

sergio


> Ya he leído por aquí 
> alguna vez que sería interesante para el mapeado de puntos de interés 
> (recorrer una serie de calles siguiendo el camino más corto), y es algo 
> que consideramos para una futura versión, aunque también animo a 
> cualquiera a que se baje nuestro código y lo modifique para añadir esta 
> o cualquier otra funcionalidad.
>   
>> ___
>> 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 mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Plugin de cálculo de rutas para JOSM

[Juan Guillermo Jordán Aldasoro]

sergio sevillano escribió:
> Pedro-Juan Ferrer Matoses escribió:
>   
>> ¡Excelente noticia!
>>
>> ¡Enhorabuena!
>>
>>   
>> 
> muy bien!
>
> a ver si algún día vemos un plugin para el cálculo del "problema del 
> cartero chino"...
>
>   
Supongo que te refieres al traveling salesman. Ya he leído por aquí 
alguna vez que sería interesante para el mapeado de puntos de interés 
(recorrer una serie de calles siguiendo el camino más corto), y es algo 
que consideramos para una futura versión, aunque también animo a 
cualquiera a que se baje nuestro código y lo modifique para añadir esta 
o cualquier otra funcionalidad.
> ___
> 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] Plugin de cálculo de rutas para JOSM

[sergio sevillano]

Pedro-Juan Ferrer Matoses escribió:
> ¡Excelente noticia!
>
> ¡Enhorabuena!
>
>   
muy bien!

a ver si algún día vemos un plugin para el cálculo del "problema del 
cartero chino"...

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Plugin de cálculo de rutas para JOSM

[Pedro-Juan Ferrer Matoses]

¡Excelente noticia!

¡Enhorabuena!

-- 
Pedro-Juan Ferrer Matoses
Ingeniero en Geodesia y Cartografía
Valencia (España)

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] intersección vías con rotonda a dist into nivel

[sergio sevillano]

Celso González escribió:

On Fri, Mar 27, 2009 at 09:05:10PM +0100, sergio sevillano wrote:
  

el otro día hablé sobre como tagear una
intersección vías con rotonda a distinto nivel.
y había dos puntos de vista [2] y [3]

en el caso de que fueran a mismo nivel [1]
está la regla de que la rotonda toma el color y ref
de la más importante.

pero en el ejemplo [2] la rotonda es parte de la motorway
ya que se considera motorway_link más importante que la tertiary
o bien la rotonda sería tertiary y motorway_link solo son los laterales?
como en [3]

entonces, 2 o 3?
sergio



Buf ya es hilar muy fino, dudo que incluso en Fomento tengan claro estos caso
Personalmente me gusta más 3
  

de acuerdo


Se usa la más "importante" del nivel en el que se encuentra la rotonda

  


___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] intersección rotonda con puentes y rel ación de prohibición de giro

[sergio sevillano]

Pablo Gómez escribió:
> sergio sevillano escribió:
>   
>>
>> Como podéis ver ya se ha resuelto el tema de la rotonda.
>> lo has hecho tú, Pablo?
>> bueno mando un par de links
>> de como se comporta un navegador con ella
>> http://www.yournavigation.org/?flat=40.431268&flon=-3.660639&tlat=40.435591&tlon=-3.659498&v=motorcar&fast=1&layer=mapnik
>> http://www.yournavigation.org/?flat=40.429904&flon=-3.664859&tlat=40.435591&tlon=-3.659498&v=motorcar&fast=1&layer=mapnik
>>
>>   
>> 
>
> No, no he tocado nada. Está claro que en el ejemplo 1 la cosa no
> funciona. Pero eso pasará en todas las uniones (típicas) en V de salida
> de rotonda hacia una vía de doble sentido. Otro ejemplo:
>
> http://www.yournavigation.org/?flat=40.429904&flon=-3.664859&tlat=40.435591&tlon=-3.659498&v=motorcar&fast=1&layer=mapnik
>
> O el rutado funciona mejor, o habrá que establecer restricciones en
> todas las uniones como esa. 
uf!
demasié, no?

> Hay navegadores comerciales que te permiten
> elegir si quieres tener en cuenta "U turns" o "180s" en el cálculo de tu
> ruta. Desde mi punto de vista, la pelota está más en el lado del navegador.
>
>   
eso
> Un saludo!
> Pablo
>
>
>   
>> sergio
>>
>>
>>
>>
>> ___
>> 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 mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

[Talk-es] Plugin de cálculo de rutas para JOSM

[Juan Guillermo Jordán Aldasoro]

Buenas. Hemos desarrollado un plugin de cálculo de rutas [1] para JOSM.
Se llama routing y está disponible para las últimas revisiones de JOSM.

Por el momento tiene la siguiente funcionalidad:

  Cálculo de ruta multidestino.
  
Añadir nodo
Eliminar nodo
Mover nodo

  
  Ruta inversa.
  Criterios de cálculo
  
Más corta
Más rápida
  
  
Ignorar oneways.
  
  Ajuste de pesos para los distintos tipos de highway.
  


En esta versión no se tienen en cuenta las relaciones (restricciones).
El código fuente también está disponible en el repositorio de
openstreetmap.

Saludos
Juangui

[1] http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Routing



___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es