Re: [Talk-es] IGN topo

[Diego García]

wms:
http://www.ign.es/wms-inspire/mapa-raster?SERVICE=WMS=image/png=TRUE=1.1.1=WMS=GetMap=mtn_rasterizado=={proj}={width}={height}={bbox}

Un saludo,

El vie., 10 abr. 2020 a las 19:23, Javier Izcue ()
escribió:

> ¿Alguien me podría decir como ver el IGN Topo en las imágenes de JOSM?
> Me gustaría hacer alguna comprobación con el IGN Topo y no me sale entre
> las imágenes predefinidas. Tampoco he sido capaz de añadirla. Muchas
> gracias.
>
>
> --
> El software de antivirus Avast ha analizado este correo electrónico en
> busca de virus.
> https://www.avast.com/antivirus
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] hello, first message tried in this list

[Diego García]

Esto ya es surrealista.

¿Usted a qué ha venido por aquí? ¿A mapear o a sacarnos de la ignorancia,
como en el 1808? ¿Cuántos años lleva usted viviendo aquí como para
discutirnos? ¿Conoce mínimamente la realidad de España, o sólo lo que
encuentra por internet? Se está retratando usted solito. Se lo pido por
favor: deje de hostigar a toda una comunidad nacional, le invito a irse por
donde ha venido, déjenos en paz. Hay muchas cosas para editar en su propio
terreno si le parece bien. O en el Congo Belga, o en Laponia. La wiki de
OSM me han dicho que está muy bien en esta época del año.

Disculpe la ocurrencia, no es mi estilo en público. Pero la paciencia tiene
un límite muy fino, y usted se lo lleva saltando desde hace demasiado
tiempo.


Un saludo, a todos menos a uno,

Diego

pd.: Supongo que su respuesta airada no se hará esperar. No se preocupe,
encajo bien. De todas formas aquí termino, no pienso gastar ni un minuto
más con usted.

El sáb., 25 ene. 2020 a las 6:05, Philippe Verdy ()
escribió:

> Another reading if you've missed that Aragonese law:
>
> (Boletín Oficial de Aragón n°149, 2006-12-30, Gobierno de Aragón).
>
> Decreto legislativo 2/2006 de 27 de diciembre del Gobierno de Aragón por
> el que se aprueba el texto refundido de la Ley de Comarcalización de Aragón
>
> http://www.boa.aragon.es/cgi-bin/BRSCGI?CMD=VEROBJ=167404590505
>
> Le sam. 25 janv. 2020 à 03:01, Alejandro S.  a écrit :
>>>
 Dear Phillipe,

 I've been living in Zaragoza (Aragón, Spain) for 27 years. Please,
 don't tell I don't know what a Comarca is.

 I think Pepe has been pretty clear telling us the laws regarding this
 issue:

 *"Oficialmente, insisto, oficialmente la Ley de Bases de Regimen Local,
 es la que especifica la division territorial y administrativa de este país.
 Y es clara en su articulado en lo que a limites se refiere: Pais, Comunidad
 Autónoma y Ciudades Autónomas, Provincia, Municipio y Entidad Local Menor a
 municipio (las conocidas como Juntas Administativas Locales, Pedanias,
 Poblados, e incluso Parroquias o anteiglesias) el resto no son más que
 divisiones de gestión de diferentes organos generalmente para optimizar sus
 medios y servicios y no pueden estar en estos niveles pues legalmente no
 existen."*

 I'm not sure if we're just overthinking or feeding a troll.

 Best regards,
 Yonseca.

>>>
> These evidences above (including the names of documents, their dates, and
> assertable links that any one can see easily) were already made before, but
> you did not care about reading them. Think twice before accusing someone of
> "trolling".
>
> So I supposed you just lived in Aragon *before* February 2006 and have not
> seen what happened there after you left. Or you are not jut interested
> yourself by this subject which others consider useful and are legitimate in
> OSM (and if you still don't trust what was put in OSM, you can compare with
> the published open data of these administrations).
>
> An official comarcalization occured also in Galicia, but Catalunya was the
> first to make it official at regional level.
> The juntas of provinces have still not understood that, they contiunue to
> use their own touristic comarcas, or may maintain them only as statistical
> units for reasons of continuity over a period long enough to be able to
> report analyze the evolutions. But provinces have no statistics intitutes.
> Aragon has its own official statistics institute (IEAST, whose website is
> for now the same as the Gobernatio).
>
> The Spanish State government is also late on this in its ministerios and
> othert state agencies (but the state government make that for other
> planning purposes, not to rule what and how comarcas are regionally
> organized, because it is not the competence of these adminsitrations, they
> have no power to create or change them officially and give them a judicial
> identity or any form of autonomy; only the Spanish parliament *may*
> eventually do that, but it won't be consititutionally able to legiferate on
> domains whose competence were transfered to the autonomous communities,
> without negociating with their respective governments).
>
> The question is not if those comarcas should exist or not. Of course they
> should be there. It's only a problem for defining a tagging system, and
> using it coherently (something that is incoherent today, but there's no
> alternative documentation: someone must do the hard job of first sorting
> things to avoid incoherences, then apply the tags, that this list may
> discuss, but has to document somewhere without just placing an informal
> link to the Spanish Wikipedia article where nothing is coherent or well
> defined as the topic is clearly still not understood by most Spaniards that
> have contributed to it; the situation is even worse in Wikimedia Commons
> with lot of incohrent and undated "maps" and that was then transfered as is
> from 

Re: [Talk-es] hello, first message tried in this list

[Diego García]

Buenos días.

Por Aragón también.

No voy a andar revisando todo cada vez que interviene este editor.
Como ejemplo https://www.openstreetmap.org/changeset/79841251 donde crea
comarcas en Teruel y de paso le cambia el adminlevel a la localidad de
Monzón de 7 a 8, siendo que es la capital del Cinca Medio. Veo muchas más
ediciones, pero no me las voy a repasar todas.

Qué pereza, madre mía. Y qué paciencia.



Un saludo,






El mié., 22 ene. 2020 a las 5:15, Diego Cruz Alonso ()
escribió:

> Buenos días a todos:
>
> Lamento tener que volver a escribir a la lista en relación con este tema,
> pero el usuario Verdy_p ha vuelto a editar demarcaciones en Castilla y
> León. Ha creado dos áreas con boundary=political en la provincia de Burgos,
> una en el condado de Treviño y otra agrupando otros dos enclaves que ha
> denominado «Enclaves burgueses de Miranda de Ebro» (me aventuro a decir que
> tal cosa no existe). Por lo que veo la etiqueta boundary=political se
> utiliza en España para circunscripciones electorales y cosas así, ¿me
> equivoco? ¿Tiene sentido crear entes específicos para los enclaves con ella?
>
> Además, ha seguido creando comarcas agrarias (ahora en Palencia) sin
> esperar a que se decida en común lo que se quiere hacer con las comarcas en
> esta comunidad autónoma (invito a otros usuarios castellanoleoneses a
> participar y a todo el que quiera opinar). Cabe la posibilidad de que haya
> que borrar todas, pues la única oficial sigue siendo El Bierzo, así que es
> posible que esté perdiendo su tiempo y nos lo haga perder posteriormente si
> tenemos que borrar todo.
>
> Un saludo
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] hello, first message tried in this list

[Diego García]

 Buenas tardes, Philippe.

Para que no estemos dando vueltas en círculo, voy a dejarlo claro: ahora
veo que los límites administrativos son una combinación de adminlevel y
boundary. Visto así, efectivamente, estoy equivocado y no se han duplicado
las comarcas. Sin embargo, lo que ha hecho usted es inventarse un límite
nuevo, no sé qué es peor.

"I agree with that and I have not challanged that. It was additional
independant objects (for reference purpose only and useful for contruction
purpose and verification)."

Por favor, deme un solo ejemplo de proceso de referencia, construcción o
verificación en que sea necesario el etiquetado que usted está tratando de
imponernos, fraccionando las comarcas en objetos independientes. Etiquetado
que, por otro lado, no está documentado en ninguna parte, es una mera
invención suya. Dígame en cuál de esas leyes que ha estudiado aparece "Hoya
de Huesca (Zaragoza)". No es algo que exista ni sobre el terreno, ni como
construcción artificial de datos que se necesite.

"But if you can't understand that (at least when a complete and coherent
set of relations is built, we need additional intermediate objects (like
these few "fraction" subnelations, whose name is not important and will be
invisible, except in OSM editors) and sort and organize the long lists of
municipalities to avoid forgetting one..."

Lo entiendo perfectamente, y vuelvo a decir que los objetos fraccionarios
que usted propone son innecesarios, solo contribuyen a que todo sea más
complicado. Más arriba menciona que siguió las convenciones antes de
editar: mire, no se lo niego. Tenemos la documentación muy poco
desarrollada, comparada con otros países. Pero tengo claro que no siguió
dichas convenciones después: ¿porqué no paró cuando vió que varios editores
españoles le expresaron su disgusto con lo que usted estaba haciendo?

Conozco de sobra la situación de los límites en Aragón. Salvo las comarcas
de Huesca y algunas de Zaragoza y Teruel, el resto de comarcas no están
incluídas, y los municipios no están bien, fruto de ediciones precipitadas
al principio, y de poco cuidado después. Se habrá encontrado de todo:
fronteras rotas, etc. Y si me hubiera preguntado antes, se lo habría
contado encantado. No se imagina cómo le hubiera agradecido que viniera a
echarnos una mano limpiando municipios o completando comarcas, de verdad.
Pero ya le digo que así, no.

Escuche: le estuvimos diciendo clara y unánimemente desde la comunidad
española que no fraccione las comarcas, y usted insistió en ello y en
justificar sus acciones, sin aportar ningún argumento que convenza. Le
estuvimos diciendo también que no edite límites sin debate previo y sin
enfrentar ideas con la comunidad local de esa autonomía, y estuvo haciendo
oídos sordos y dando excusas. A pesar de todo ello no ha parado de editar
hasta que le han baneado dos veces, que es cuando realmente se ha puesto en
contacto con nosotros. Y con todo ello, todavía no le hemos visto ni una
sola vez pedir disculpas o admitir que se ha equivocado, aunque solo sea
por cortesía.



En fin, un saludo,
Diego
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] hello, first message tried in this list

[Diego García]

Estimado Philippe.

Mi caso es casi el opuesto al suyo. No hablo ni escribo en inglés, pero por
motivos laborales no me queda otro remedio que entenderlo, aunque un poco
deficientemente. Si para evitar errores en la traducción debemos utilizar
ambos idiomas, tendrá que ser así.

Lo primero que me gustaría explicarle es que su actitud no se corresponde
con un editor que lleva varios años de actividad sobresaliente tanto en
cantidad como en calidad en sus ediciones. Para que me entienda, yo jamás
me pondría a editar los límites administrativos de otro país sin ponerme
antes en contacto con el grupo de editores activo en la zona. Eso es algo
que no me entra en la cabeza, por muy colaborativo que sea el proyecto. Se
trata de un tema de educación y cortesía, además de los destrozos que se
pueden hacer si no conozco suficientemente el tema. No vale decir que
intentó ponerse en contacto con nosotros: el tema que usted editaba (los
límites comarcales) no estaba tan mal ni era tan urgente editarlo como para
emprender la tarea sin decirnos algo antes.

Sobre el tema concreto de las comarcas, trataré de ser breve. Ya hace un
tiempo que la comunidad española tratamos el tema y básicamente decidimos
que cada autonomía hiciese lo que se corresponde a la realidad allí.
Resulta que aunque haya establecida por ley una división comarcal para cada
autonomía, en la práctica no se ha aplicado por igual. Del mismo modo que
en Aragón tenemos comarcas funcionales y que se corresponden (más o menos)
con la realidad histórica y geográfica, en Castilla-León no quieren ni oir
hablar del tema. Recuerdo a otro editor diciendo, por supuesto en tono
coloquial, de cortarle alguna parte del cuerpo al que se le ocurriera crear
comarcas en su autonomía. Y estamos todos de acuerdo con ello: ¿quién va a
conocer mejor una zona que aquellos que la habitan? ¿quién debe tener la
última palabra sobre cómo editar en su zona, sobre cómo está organizada,
siempre que se atenga a las normas? Lástima que este debate se produjo en
el canal de telegram: aquí doy la razón a mi compañero Miguel, si no le
estaría pasando el enlace de la lista.

"I was told by a Spanish user to map missing comarcas in Aragon and then I
was blocked for that, even if there was no "error", and there was an
ongoing talk with existing users that did not contacted me directly on OSM
but prefer to complain to the DWG."

Me va a permitir que dude que esto sea así. Si no le importa, mencione qué
usuario le invitó a mapear las comarcas de Aragón. Y no diga que este fue
el motivo de su bloqueo: su edición errónea (porque sí lo es), fue
revertida con buenas razones, que se le indicaron en el propio conjunto de
cambios. A partir de ahí usted empezó una discusión en esa misma edición
sin querer escuchar otros argumentos, y no sólo no paró de editar, sino que
además revertió de nuevo los cambios, lo que es claramente una guerra de
ediciones. Fue entonces cuando le bloquearon, no antes. Hasta este segundo
bloqueo no se ha puesto usted en contacto con nosotros... ¿Dónde está el
malentendido? No veo buena fe en su actuación.

"About the case of Avila, there are were two different kinds of comarcas in
the same province and they would have overlapped. (...)"

Sobre el caso de Ávila, usted no propuso nada. Llegó y editó, punto. Se le
llamó la atención y no hizo caso, se limitó a aplicar su criterio.

"Spain is not more complicate than France or other countries."

No, no es más complicado. De hecho, puede que sea más sencillo. Lo que sí
son es diferentes. No me diga que ha estudiado mucho para editar aquí, lo
que tenía que haber hecho es hablar con nosotros después de estudiar para
aclarar las cosas.

Respecto a su edición en Aragón, partamos de lo que es cierto e
indiscutible:

- La organización comarcal es una agrupación de municipios de una misma
autonomía, al margen de las provincias.
- Debe existir una única relación por cada comarca, con adminlevel 7.

Cumpliendo lo dicho ya existía la relación
https://www.openstreetmap.org/relation/6479877 para definir la comarca de
la Hoya de Huesca perfectamente editada y sin errores, como hija de la
relación Aragón, e independientemente de las provincias.

Ahora llega usted y crea dos relaciones nuevas, con adminlevel 7, y se
inventa sus nombres (ya que dichos territorios no existen):
https://www.openstreetmap.org/relation/10594434 y
https://www.openstreetmap.org/relation/10594435

Esto es totalmente innecesario, e incumple las premisas antes expuestas. La
comarca acaba de quedar triplicada en su nivel 7 por otras dos entidades
que no existen. Por si fuera poco, utiliza etiquetas de su invención
"boundary administrative_fraction" y deja notas para justificar su visión
de las cosas. Incluso fue uno de los argumentos que utilizó para debatir
conmigo: "dejé una nota que lo dice". Que usted lo diga no es un argumento,
compréndalo.

Si se hubiera molestado en mirar el histórico de las relaciones de comarcas
en Aragón, habría visto que yo participé en todas, 

[Talk-es] Ediciones del usuario Verdy_p, sin consenso con la comunidad española de OSM

[Diego García]

Buenas tardes.

En España, las comarcas son una división del territorio que agrupa a varios
municipios. Se intenta, me temo que a veces sin conseguirlo, que se
correspondan a la definición de comarca, englobando una zona geográfica que
comparte características naturales y humanas comunes, en una jerarquía por
debajo de la región. Como tal agrupación de municipios, y establecidas por
separado en cada comunidad, se trata de una entidad por encima del
municipio pero por debajo de autonomía, al margen de las provincias. Se da
el caso de que hay comarcas que incluyen municipios de diferentes
provincias, lo que no supone ningún problema a la hora de editar, siempre
que dejemos de lado las provincias al trabajar el tema.

Por ejemplo, la comarca de la Hoya de Huesca, o la de los Monegros (en su
mayor parte dentro de la provincia de Huesca), comprenden municipios de
Zaragoza, sin que eso suponga un problema. No es necesario fraccionar nada,
ni tocar las provincias, ya que son una entidad aparte, que no mantiene una
jerarquía con las comarcas. Simplemente establecemos la frontera de las
comarcas y las incluímos en la entidad superior, que es la autonomía. Esto
es algo que funciona, que es como debe hacerse, y que asumimos así por
consenso desde hace años en la comunidad española de OSM.

Desde hace un par de semanas se vienen sucediendo ediciones del usuario
Verdy_p que no están teniendo en cuenta la jerarquía que tienen las
comarcas en España. Por ejemplo, en el caso de la comarca de la Hoya de
Huesca la ha dividido en dos, estableciendo una "Hoya de Huesca (Zaragoza)"
y otra "Hoya de Huesca (Huesca)", que a su vez ha incluído como partes de
la relación que ya existía. A todas ellas les ha dado admin_level 7.

https://www.openstreetmap.org/changeset/79639164

Podemos decir: "bueno, es una forma de verlo, la edición es correcta". Pero
en realidad no lo es, por tres razones:

- En primer lugar, al establecer varias relaciones con el mismo admin_level
triplica la comarca
- En segundo lugar, se está inventando el name de las relaciones creadas.
"Hoya de Huesca (Zaragoza)" no es algo que exista en ninguna parte.
- En tercer lugar, es totalmente innecesario. El mapa funciona igual de
cara a las búsquedas o a la jerarquía de territorios. De hecho, antes
funcionaba mejor. Si ahora hacemos una extracción de datos con overpass
obtenemos un batiburrillo importante.

La cuarta razón sería que no es la forma en que la comunidad española ha
decidido que se haga. Este usuario ha venido para hacer las cosas a su
manera, sin preguntar primero, y esa no es la forma correcta de actuar.

Visto lo visto, y ya que la comarca de la Hoya de Huesca estaba
correctamente editada desde hace años en el mapa, y que soy un editor local
conocedor del tema, procedí a revertir el cambio, y a avisar al usuario
Verdy_p. Con cambios pequeños se suele avisar primero y esperar a que el
mismo editor conteste, pero ante la magnitud del cambio, que afecta a
límites administrativos, lo suyo es revertir antes de que el daño sea mayor.

Los distintos mensajes que fue dejando el usuario Verdy_p en el changeset,
subieron de nivel progresivamente. Le he tratado de explicar la situación
(yo y otros compañeros): que las comarcas en España existen aparte de la
provincias, etc, pero ha seguido a lo suyo. El final ha sido que ha vuelto
a editar todo en varios cambios, con lo que ahora revertir ya sería
complicado, aparte de que entraríamos en una guerra de ediciones que ha
iniciado él.

Solo aporto el changeset que conozco de primera mano. Me consta que el
usuario lleva varios días haciendo cambios semejantes por toda España,
siendo apercibido por ello, y haciendo caso omiso a la comunidad española.
Hay autonomías en las que la comarcalización no funciona, y que por tanto
decidieron en su día no trasladar algo que en la práctica no existe al
mapa. Los demás pensamos que están en su derecho y que son soberanos en
ello, no veo porqué tiene que venir alguien que no pertenece a nuestra
comunidad a imponer otro criterio, cuando el nuestro no contraviene ninguna
norma.

Me parece una pena que un editor tan activo como Verdy_p, y con cierta
antigüedad, se dedique a entrar en estas guerras, a destruir en vez de
aportar. En el caso de Aragón, tenemos una buena parte de Zaragoza y Teruel
sin crear sus comarcas, por lo que si se hubiera limitado a terminar el
trabajo, siguiendo las reglas locales, ahora mismo le estaría aplaudiendo.
Si haces algo mal, y te lo dicen, lo siguiente es escuchar lo que te dicen,
y esto no ha ocurrido. Como podeis ver por el changeset, no escucha, sólo
vale su criterio. Y si nos asomamos por otros lugares, la wiki por ejemplo,
vemos que su comportamiento viene de lejos.
https://wiki.openstreetmap.org/wiki/User_talk:Verdy_p#Blocked

Escribo a la lista para que mis compañeros puedan aportar algo más sobre el
tema, y para decidir qué acciones tomar, en caso de que lo estimemos
necesario, de cara a que el usuario Verdy_p desista en su comportamiento.

Re: [Talk-es] Etiquetado de algunos elementos religiosos: capillitas callejeras, peirones, cruces de término...

[Diego García]

Buenas tardes, Lanxana.

Me parece un tema muy interesante. Hice un trabajo fotográfico sobre
ermitas, cruceros, etc hace un par de años y me apoyé en OSM para localizar
los sitios, para lo que traté de seguir un etiquetado coherente en la zona
que trabajo habitualmente.

En lineas generales creo que tu etiquetado es correcto, pero pienso que no
debería utilizarse place_of_worship para los cruceros y peirones. El
significado de la etiqueta sería lugar de culto, y ese tipo de elementos no
lo son, aunque tengan la mayoría de ellos un caracter claramente religioso.
Debería quedar reservado para lugares en donde se celebra el culto, es
decir, ermitas, iglesias, algunas capillas, etc. Por el mismo motivo,
tampoco creo que deba aplicarse a las hornacinas que podemos ver en
fachadas.

En resumen, el etiquetado que creo correcto debería ser:

* Iglesias: amenity=place_of_worship + building=church
* Ermitas: amenity=place_of_worship + building=chapel
* Capillas: building=chapel. Ojo, normalmente una capilla es un espacio
reservado para el rezo, muchas veces de acceso privado, aunque hay
excepciones en las que se celebra (por ejemplo, en hospitales,
tanatorios,...), pero estarían como cuarto dentro de un edificio
(building:part), por lo que normalmente no se mapean. Si se trata de un
elemento edificado aparte, o con acceso desde calle, sí es más normal que
se mapee, y si se celebra culto llevaría place_of_worship. Es el típico
ejemplo de elemento que conviene conocer, a ser posible de primera mano,
para decidir sobre su etiquetado.
* Esconjuraderos: building=shrine
* Hay un tipo de ermita de pequeño tamaño que tiene abierto uno de sus
lados, y que entraría de lleno en la definición de shrine. En mi zona se
llaman zoques, no sé cómo se llaman en castellano. En ellos se celebra
culto, por lo que se diferenciarían de los esconjuraderos en que llevarían
amenity=place_of_worship
* Cruces de término y humilladeros: historic=wayside_cross
* Peirones: historic=wayside_shrine + support=pedestal
* Hornacinas: historic=wayside_shrine + support=wall
* Ruinas si tienen las cuatro paredes: building=ruins +
historic=chapel|church|etc (en el mismo elemento) NUNCA place_of_worship
* Ruinas (sólo algunos muros derruidos): barrier=wall + ruins=yes, más un
nodo aparte con historic=chapel|church|etc NUNCA place_of_worship

Al final ya ves que me ha convencido lo de historic=wayside_shrine para las
hornacinas, que es lo que suscitó el debate inicial, siempre que lleve algo
que lo diferencie de un peirón. Lo que no veo de ninguna manera es
amenity=place_of_worship para elementos en los que no se celebra.

No digo nada del resto de etiquetados (religion, name, inscription,
star_date), ya que son informaciones que doy por supuesto que se introducen
en caso de conocerlas o ser relevantes.



Un cordial saludo,




El mar., 14 ene. 2020 a las 18:47, Lanxana . ()
escribió:

> Buenas tardes,
>
> Hace un tiempo que quiero etiquetar las capillitas que voy encontrando por
> la calle, y a raíz de hacer la consulta, aparecieron referencias a otro
> tipo de elemento religioso, el peirón, así que para facilitar la tarea y
> poder plasmar luego el etiquetado a la wiki de “Como mapear un…”, he
> investigado sobre ambos elementos, para tener claro a qué se refieren y ver
> qué etiquetado se les ajusta mejor. Por un lado, tenemos estos dos
> elementos:
>
> 1 – “Capelleta de carrer”, capillita callejera, oratorio, hornacina…  [1]
> Son representaciones religiosas de vírgenes y santos, en forma de escultura
> dentro de una hornacina, o composiciones de azulejos decorados, que se
> encuentran en algunas fachadas de edificios por la calle, en un plano más
> elevado que el observador [2]  y [3]. Su función podría ser tanto bendecir
> al viajero que transita por la calle como fomentar la fe popular.
>
> 2 – Peirón, “peiró”, humilladero, cruz de término… [4]. Con este elemento
> ha sido todo un descubrimiento ver las distintas maneras de referirse a él,
> y tengo mis dudas de si realmente podríamos hablar de un mismo tipo de
> elemento, o serían distintos elementos con funciones distintas. A grandes
> rasgos, tanto el peirón como la cruz de término serían dos tipos concretos
> de humilladeros. Según recoge la RAE, humilladero es  un “lugar devoto que
> suele haber a las entradas o salidas de los pueblos y junto a los caminos,
> con una cruzo imagen.”
>
> Y por otro lado, el etiquetado recogido en la wiki:
>
> A – historic=wayside_shrine [5]: “A shrine placed by a road or pathway
> showing a religious depiction.” (Santuario histórico que a menudo muestra
> una representación religiosa)
>
> B – building=chapel [6]: “A chapel is a religious building, often pretty
> small. One can enter in it to pray or meditate.”
>
> C – building=shrine [7]: “Buildings tagged with building=shrine are at
> least large enough to hold a single standing person along with the contents
> of the shrine, though access might be restricted to just the operator. Many
> shrines can be much 

Re: [Talk-es] Uso de landuse=residential

[Diego García]

Buenas tardes.

Yo sí le meto bastante tiempo a mapear coberturas y usos del suelo, y
coincido contigo.

- Límites compartidos: no debería ser jamás de los jamases, sino que
debería tener cárcel. No os imagináis los problemas que da eso cuando viene
detrás otro editor añadiendo o corrigiendo cosas. Sólo tienen que compartir
nodos con otros usos del suelo. Lo contrario queda mal estéticamente y no
tiene sentido sobre el mapa. Un camino que comparte nodos con un bosque...
¿qué ocurre si ajustamos la geometría del camino porque está hecho unos
zorros? ¿estamos diciendo que se ha movido la línea del bosque? El camino
está dentro o fuera, lo cruza o va paralelo al borde, pero no debe
compartir nodos con el bosque. Y con landuse residential ocurre lo
mismo. *Excepción
a todo esto*: los límites administrativos, que sí pueden compartir nodos
con polígonos de usos del suelo y coberturas, tanto en el mapa como en la
realidad. Puede haber más excepciones, pero ahora mismo no se me ocurren.
- Respecto al dibujo del área: cuando me encuentro con que no hay nada
hecho, yo suelo empezar por seguir la línea del catastro. Da una idea muy
buena de por dónde van los tiros, y lo deja casi terminado. A partir de
ahí, a dibujar casitas y, cuando ya las he terminadoo, o incluso al mismo
tiempo, refino los límites del polígono con lo que me he encontrado.
Estamos mapeando la realidad, no perdamos eso de vista. Por mucho que el
catastro diga que una zona es residencial, si no hay absolutamente nada en
ella (ni edificios ni gente viviendo), no es landuse residential. Y
viceversa.
- El landuse residential debería abarcar toda la población. ¿Se puede
dibujar uno por manzana? Pues sí, se puede, pero no tiene sentido alguno:
¿hay alguna diferencia entre una manzana y la siguiente? Si lo hacemos
estamos complicando el mapa sin aportar información, y corremos el riesgo
de compartir nodos del landuse con otro elementos sin necesidad.
- Añado para que quede claro: las landuse residential no deben llevar la
etiqueta name, a excepción de urbanizaciones, barrios, etc, separados del
núcleo principal, cuando sí tengan un name. Si no tienen name, dejamos el
teclado en paz y no se pone, que a veces parece que hay obsesión con poner
name a todo. El name de una localidad va siempre en el place. Cuando
dibujas una landuse residential lo que haces es declarar que esa zona está
destinada a habitación, nada más. ¿Es que el polígono industrial que hay
junto al área residencial no forma parte de la población? Si pones name al
landuse residential es eso exactamente lo que estás diciendo.

En resumen: landuse no debe compartir nodos con otros elementos (salvo
otros landuse y límites administrativos), debería abarcar toda el área
poblada (al margen de lo que diga el catastro), y no lleva name (salvo
núcleos separados del principal). Vamos, que creo que estamos de acuerdo en
todo, y que lo único que veo que podría dar debate es cuando se dibuja un
landuse por manzana, lo que en mi opinión es innecesario por los motivos
que he expuesto antes.

Y añado, porque veo algunos de vez en cuando por mi zona: poner landuse
residential más place village sobre un pueblo abandonado debería estar
penado por la ley.


Un cordial saludo,



El vie., 6 dic. 2019 a las 12:19, Lanxana . () escribió:

> Buenos días,
>
> a raíz de una duda que se planteó el otro día sobre el uso de la etiqueta
> landuse=residential, he consultado la wiki para ver cómo está documentado y
> cuál sería su uso según el nivel de mapeo que queramos dar.
>
> A día de hoy me he encontrado estas situaciones:
> - área que envuelve todo el núcleo urbano, en algunos casos según
> clasificación de catastro, en otros según cartografía, en otros según
> imagen aérea y en otros según criterio particular
> - área que envuelve varias manzanas, pueden haber varias en un mismo
> núcleo urbano, y algunas veces incluso solapadas entre ellas. En algunos
> casos hay otra área envolvente también etiquetada con landuse=residential
> - área que envuelve una única manzana
>
> A esta casuística se añade las de:
> - límites coincidentes con otros elementos, como carreteras, límites
> administrativos, otros usos del suelo
> - áreas con nombre y otras sin
>
> Creo que sería interesante abrir un debate sobre cómo mapear las áreas
> residenciales para intentar lograr un consenso o línea general de trabajo.
> Por ejemplo, el criterio que suelo utilizar es el siguiente:
> - respecto a los límites, nunca, jamás de los jamases, compartido con
> carreteras o límites administrativos. Para mí el único caso lógico para
> compartir un límite es con otro uso del suelo.
> - respecto al área, para un mapeo general, área envolvente al núcleo
> urbano. En caso de núcleos desagregados, algunas veces he puesto el nombre
> en el área, aunque según se documenta en la wiki no sería necesario.
> - como no me he puesto aún con los usos del suelo, más allá del de
> cementerios y polígonos industriales, no tengo un criterio claro sobre si
> aplicar 

Re: [Talk-es] Toponimia en Galicia

[Diego García]

Buenas tardes.

El debate era positivo cuando comenzó. Hace bastante que ha dejado de serlo.

Te escribo desde una comunidad donde se hablan tres lenguas diferentes.
Mientras una de ellas impera desde hace ya siglos, y a otra se le ponen
nombres raros para no reconocer lo que es por pura mezquindad con nuestros
vecinos, hay una tercera menospreciada, arrinconada, ignorada, negada su
existencia y llevada hasta casi su extinción. Aquí sí habría debate sobre
lo que se pone en la etiqueta name. Aquí si entramos en el terreno de las
opiniones, aunque tengo clara la mía y cuál es la lengua mayoritariamente
hablada y propia de mi territorio: negar la historia no sirve de nada. ¿Lo
habría también para la etiqueta name:es? En mi opinión, no, bajo ningún
concepto.

Si quieres que tu lengua se imponga sobre otras, este no es el foro. Yo,
por lo menos, no voy a seguir con ello y menos con gente que no razona.
Puedes creerme si te digo que este tipo de "debates" me hace plantearme mi
continuidad en el proyecto.


Un saludo,

El lun., 9 sept. 2019 a las 18:35, Miguel Branco ()
escribió:

> Entiendo lo que queréis decir, aunque no lo comparta. Nota: no quería
> enredar más el debate así que dejo lo de deturpación a un lado (disculpad,
> con ello me refería a un proceso histórico) y entendedlo como traducción al
> castellano, o español, como prefiráis.
>
> Resumiendo lo que quería expresar, es que en Galicia, donde están los
> topónimos de los que hablamos, la ley gallega, ratificada por el congreso
> español, indicó que solo hay una variante para ambos idiomas. [Otras
> entidades, como la RAE, discrepan y dicen de otro modo, lo sé.] Así que lo
> que quería expresar es que entiendo que los ponferradinos, argentinos o
> londinenses hispano-hablantes quisierais usar también en name:es en otras
> formas. Pero muchos gallegos, castellano hablantes también, queremos tener
> OSM en castellano y con los nombres oficiales de nuestros pueblos y
> ciudades. Si, caso ficticio, el castellano no se hablase en Galicia a esto
> que digo le vería poco sentido. Pero sí que es oficial en Galicia, y creo
> que también podemos decir algo sobre ello, ¿no?
>
> Sobre la localización, como comprenderás me gustaría tener más software en
> gallego (y trabajo en ello), pero a muchas compañías no les interesa o no
> pueden invertir en ello. Aunque tenga mis dispositivos configurados para
> usar ese idioma, a veces me encuentro con ese caso que comento. Las lenguas
> con más hablantes tenéis más opción de elección en ese sentido. Por ello lo
> de que creo que alt_name os suple lo suficiente. Os ponía ese ejemplo para
> expresar, en mi opinión, que no es tan superflua esa etiqueta.
>
> @dcapillae sabiéndolos incluiría adaptaciones a otros nombres, pero en
> general veo que en otros idiomas no suele haber problemas en adaptar el
> topónimo local (p.ej. inglés). @Diego, aunque cuesten estos debates creo
> que son positivos para la comunidad. Continuemos expresando nuestra postura
> y a ver en que resulta.
>
> Uns saúdos!
>
>> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Toponimia en Galicia

[Diego García]

Buenas tardes.

He seguido todo el hilo y algunas partes en el canal de esta extraña
discusión.

Primero: el nombre "oficial", el recogido por la legislación, el topónimo
que se utiliza en ese lugar en la lengua que le es propia, es el que
aparece, o debe aparecer, en la etiqueta name. Fácil, ¿no?.
Segundo: el nombre en cada uno de los idiomas con el que se conoce un
topónimo, es el que aparece o debe aparecer en la etiqueta name: y el
código del idioma correspondiente. También chupado.

¿Tan difícil es de entender? Sólo son dos puntos, dos definiciones que no
admiten cambio.

Esto no lo digo yo. Lo dice la comunidad, lo dice OSM, lo dicen los mapas,
lo dice el sentido común, y no admite discusión. ¿Dónde está el posible
debate? ¿O estamos hace mcho tiempo frente a una tontería de tintes
políticos que no tendría cabida en OSM, ni en la lista de correo, ni muchos
menos en el canal, ya que allí está expresamente prohibida? ¿De verdad
nadie más que Daniel (y alguno más al que sinceramente agradezco leer) se
da cuenta de la estupidez y la pérdida de tiempo monumental que representa
todo esto?

Lo tenía que decir: comprendo que en un inicio aparezca el debate en el
hilo, como duda, o como un "quizá debería ser así". Pero a estas alturas de
la película sólo siento vergüenza ajena por todo lo que estoy viendo.

Un saludo,

El lun., 9 sept. 2019 a las 17:22, dcapillae ()
escribió:

> Buenas tardes.
>
> El topónimo en español es «La Coruña». Lo uso yo, lo usan en Argentina,
> Uruguay y Colombia. Lo usamos millones de hispanohablantes en todo el
> mundo.
> No tenéis razón al intentar imponer como topónimo en español el nombre en
> gallego. Es contrario a la realidad, contrario a la razón y a las
> convenciones de OSM. ¿Por qué lo hacéis? Ya lo sabemos. [1]
>
> «La Coruña» no es otro nombre de A Coruña (alt_name), es el nombre en
> español (name:es). «La Coruña» no es el nombre antiguo en español, es el
> nombre en uso en español. Si se desea hacer constar que en el pasado solo
> tenía un nombre y era el nombre en español, me parece bien. Es un dato
> histórico de incontestable interés. En ese caso, se puede añadir
> «old_name=La Coruña», pero dejando el topónimo en uso en español,
> «name:es=La Coruña», y el nombre en gallego en la etiqueta «name».
>
>
> Miguel Branco wrote
> > Obviamente se debe hacer una traducción de "Rúa de..." > "Calle de ..."
> > pero nunca del topónimo.
>
> Ya lo he dicho en este foro. «La Coruña» no es la traducción de nada, es el
> topónimo en español. «Londres» no es la traducción de «London», es el
> topónimo en español. ¿Por qué insistís tanto en eliminar el topónimo en
> español? ¿Por qué no elimináis también el topónimo en euskera o en francés?
> ¿O solo interesa ocultar el topónimo en español? Es una pregunta retórica,
> obviamente. Las intenciones políticas de estas acciones ya han quedado de
> manifiesto. [1]
>
>
> Miguel Branco wrote
> > Hay topónimos deturpados (La Coruña, Orense, Villagarcía de Arosa y un
> > largo etc.) que a veces se pueden encontrar en algún cartel o texto, pero
> > aquellos que se muevan por Galicia raramente los verán o escucharán.
>
> ¡Hola! Aquí el resto del mundo. Hay más cosas además de Galicia. En
> Argentina se usa el «deturpado» topónimo en español. Yo lo uso, como
> millones de hispanohablantes. La Real Academia de la Lengua lo recomienda.
> ¿Queda algo de inteligencia en Galicia? ¿Queda algo de inteligencia en el
> resto de España? ¿Hay alguien ahí? ¿Os parece adecuado decir que los
> topónimos en español que usamos millones de hispanohablantes son nombres
> «deturpados» (feos, deformados)? ¿Os parece que es así cómo debemos hablar
> de los idiomas en OSM? Un poco más de respeto por las lenguas y las
> comunidades lingüísticas no nos vendría mal.
>
>
> Miguel Branco wrote
> > Por otra parte, introducir una etiqueta name:es con topónimos como "La
> > Coruña" tiene una consecuencia directa en software, aplicaciones móviles,
> > páginas web que usen OSM etc.
>
> Obvio que sí, ofrecer un mapa multilingüe adaptado al idioma predeterminado
> por el usuario. ¿Cuál es el problema? Si un usuario no sabe configurar su
> dispositivo en otro idioma, pues que aprenda. Si quiere un mapa en gallego,
> que lo ponga. Si lo quiere en ruso, también se lo ofrecemos.
>
>
> Miguel Branco wrote
> > Y [4], por último, ninguna administración se podría/debería permitir usar
> > y publicar recursos elaborados con/o sobre OSM si éste no tiene los
> > topónimos que determina legislación vigente.
>
> Eso es falso. Todos los topónimos en OSM, al menos en España, siguen la
> legislación vigente. Todos los topónimos oficiales ocupan la etiqueta
> «name». Ninguna Administración va a tener ningún problema con eso. De
> nuevo,
> ¿por qué solo queréis eliminar los nombres en español? [1]
>
>
> Miguel Branco wrote
> > En conclusión, mi opinión es que si queremos un mapa de calidad, que se
> > use en cualquier ámbito, debemos seguir la legislación(*) y fuentes
> > oficiales y dejar 

Re: [Talk-es] Cambio de nombres en 160 cimas del pirineo aragonés. ¿Los dejamos o se cambian?

[Diego García]

Buenas tardes a todos.

Yo no lo tengo nada claro, pero en ningún caso optaría por la nomenclatura
bilingüe, como parece que apunta Miguel. A partir de aquí, apunto tres
ideas:

- Para empezar, está claro que se deben editar un name:es y un name:an, con
los nombres en español y aragonés respectivamente, siempre que estos
existan y sean correctos. Creo que eso no es cuestionable, y se puede
aplicar a cualquier otro elemento del mapa.
- El tema concreto de los nombres de los picos tiene bastante controversia.
Ha surgido de un intento de "aragonizaloquepuedas" que ha llevado a nombrar
algunos picos en aragonés que nunca se han llamado de esa manera. Estoy a
favor del conocimiento, difusión y uso del aragonés, pero nunca de su
imposición.
- Por ello yo pondría los nombres propuestos por la DGA en la etiqueta
official name, que para eso está. Y en name, los nombres reconocibles en
español, salvo cuando el nombre en español está inventado tal cual,
fenómeno bastante extendido por nuestra tierra y especialmente en los
Pirineos.
- Y, en general, utilizar el sentido común, aunque ello implique revisar
uno por uno la lista de nombres.


Un cordial saludo,



El mié., 10 oct. 2018 a las 10:11, Miguel Sevilla-Callejo (<
msevill...@gmail.com>) escribió:

> ops... en árabe, no
> name:an es aragonés, disculpad
>
> --
> *Miguel Sevilla-Callejo*
> Doctor en Geografía
>
>
> On Wed, 10 Oct 2018 at 10:02, Miguel Sevilla-Callejo 
> wrote:
>
>> Hola,
>>
>> El tema de la nueva toponimia aragonesa lo hemos debatido brevemente
>> entre los editores en Aragón. Espero se pronuncien ellos también.
>>
>> En la línea de lo que comenta Roberto, creo que es prioritario añadir el
>> "name:ar" (si es aragonés) o "name:cat" (si es catalán) más que distinguir
>> entre nombres oficiales (official_name) , que pueden incluirse igualmente,
>> como indica Roberto.
>>
>> Sin duda en "name" (genérico) ha de ser el que se usa "mayoritariamente"
>> y encontramos en los mapas, pero ojo, si existen picos que son llamados en
>> dos idiomas, yo soy partidario, como se indica en la wiki [1] para otras
>> circunstancias bilingües y como espuse en su día para el caso galés [2] ,
>> que se use aquel que combina los dos idiomas. De otro modo quedará
>> desequilibrado un idioma frente a otro.
>>
>> Recordad que no hay que editar para el render, que cada etiqueta tiene su
>> cometido, es por ello que sigo apostando por la inclusión del nombre
>> bilingüe, siempre que sea sensato, en la categoría de "name" (genérica).
>>
>> Saludos
>>
>> Miguel
>>
>> [1] https://wiki.openstreetmap.org/wiki/Multilingual_names
>> [2]
>> https://lists.openstreetmap.org/pipermail/talk-gb/2017-August/020465.html
>>
>> --
>> *Miguel Sevilla-Callejo*
>> Doctor en Geografía
>>
>>
>> On Tue, 9 Oct 2018 at 21:36, Roberto geb  wrote:
>>
>>> Alberto,
>>>
>>> Bienvenido a la lista.
>>>
>>> Te daré mi opinión:
>>> - official_name: yo pondría aquí los nuevos nombres, usando el sufijo
>>> del idioma, como por ejemplo official_name:es.
>>> - name: se usa con el nombre común. Si el cambio de nombre es reciente
>>> tal vez haya poca gente que conozca los picos por sus nuevos nombres.  Yo
>>> dejaría aquí el nombre antiguo si es de uso común.
>>> - old_name: si el nuevo nombre es utilizado comúnmente pon aquí el
>>> nombre antiguo y en name el nuevo.
>>>
>>> Que sigas disfrutando de tu  reto con los tresmiles.
>>>
>>> El mar., 9 oct. 2018 15:30, Alberto Llorente 
>>> escribió:
>>>
 Hola compis, me comentaron (con buen criterio) que éste tema que puse
 en el grupo Telegram mejor lo pusiese aquí, así que me estreno copiando y
 pegando mi mensaje. Quizá ya esté tratado pero no lo he encontrado. Si está
 tratado y acordado, agradecería conocer esa info para atenerme a ella, of
 course.
 ..

 Estoy motivado  terminando de hacer los 217 tresmiles del pirineo
 (hacer a pata, no en el mapa). De eso "algo" controlo. Acabo de empezar a
 editar y voy corrigiendo cositas que estaban con errores burdos en posición
 y nombre y pregunto:

 Dados los nuevos datos de la lista oficial y la nueva toponimia oficial
 del gobierno de aragón para 160 cimas de más de 3000 m (tema polémico para
 tratar aparte), que fue cambiada en 2017 (Documento oficial:
 http://aragonhoy.aragon.es/index.php/mod.documentos/mem.descargar/fichero.documentos_P3_6c4f221f%232E%23pdf
 )

 ¿Cuáles serían los atributos correctos de Name?:

 https://wiki.openstreetmap.org/wiki/ES:Key:name

 Tenemos Name a secas y un montón de variantes. Seguramente esté esto ya
 definido, pero no lo encuentro. Supongo que habrá que poner Name = el
 nombre oficial y luego alt_name el clásico, pero ... antes de meter la
 gamba, pregunto.

 Ejemplo:
 antes se llamaba "Pico de los gemelos" (zona Posets)
 ahora se llama oficialmente "Punta de las Mardaneras / Tuca d'els
 Chiminucs S" (si alguien lo ve, no lo va a identificar ni de coña y pensará

Re: [Talk-es] Más sobre la categorización administrativa de vías en OSM

[Diego García]

Buenas tardes, yopaseopor.

Estoy de acuerdo con Jorge. No he estado contestando correos anteriores ni
conversaciones sobre el tema en el canal de telegram, y (no te ofendas, por
favor) un buen motivo es que sigo sin ver respuestas claras y concisas a
planteamientos que se te hacen en el debate.

Cambiar el valor de una etiqueta según parámetros que no son los del
significado original de la etiqueta es perder información, nunca ganarla. Y
da igual que hablemos de parámetros físicos o de si se usa o no una vía. Si
quieres un mapa que refleje los fenómenos que tú quieres que aparezcan,
programa un render que lo haga y añade etiquetas que sumen información. No
me parece buena idea cambiar el significado de las etiquetas que ya existen
para ello.

El único punto que veo que hay cierta unanimidad, y lo comparto, es que
algunas trunk deberían ser primary, pero no por motivos puramente físicos o
de otro tipo, sino funcionales, lo que sería acorde al significado de
highway.



Un cordial saludo,




El sáb., 12 may. 2018 a las 17:07, Jorge Sanz Sanfructuoso (<
sanc...@gmail.com>) escribió:

> Primero te pido que hables del tema por favor. La mitad del texto es paja
> y al final te pierdes leyendo tanta cosa que no importa ni tiene que ver
> para lo que estamos hablando como que si aunque no sea de pago la carretera
> la pagamos todos. Por favor vete al tema y no tendremos textos inmensos que
> no aportan al final ni la mitad de lo que ocupan. Solo disuaden de mirar el
> tema. Intentare opinar de lo que no me he perdido leyendo.
>
> La gente hace más rutas que ir de un lado a otro del país. A veces
> simplemente es que por una zona pasa más gente que por otras porque vive
> mas gente, porque es una zona de ir a trabajar,... Y por eso puede haber lo
> del mapa "a topos" en cuanto a métricas. Que conste que yo tampoco le vería
> problemas a un mapa "a topos" si tuviera un sentido.
>
> En cuanto a los temas del cambio en otros países, creo que lo correcto es
> saber que criterios han seguido ellos para ver si vamos por el camino
> correcto o no. Decir que han cambiado sin saber como y porque no lo veo
> útil.
>
> No veo necesario bajar categorías como ya he comentado, aunque también he
> dicho que si cambia lo que veo algo viable es lo de las carreteras
> paralelas a autovías. Pero bajar la categoría. No ponerla por los suelos.
> Poner tertiary carreteras para entrar en ciudades, entrar en pueblos
> grandes, carreteras que sirven de acceso a secundary o primary... No lo
> veo. No se hace en otros casos, pero si es una antigua nacional si lo
> hacemos?. Si se hace eso primero hay que cambiar el etiquetado entero de
> carreteras de todo el país y bajar todo de categoría.
>
> Tu eres el primero que dice que no quiere que porque una carretera empiece
> por N o por otra cosa tenga cierta categoría pero tu eres luego el que dice
> que si se cambia una letra al final si es menos importante. Lo veo una
> contradicción.
>
> El ejemplo que he pasado es tan perfecto que hace 2 meses he ido con una
> persona de allí de toda la vida, nació allí y si ha preferido salir por la
> primera salida viniendo desde Salamanca que por la última para ir a la
> DSA-359. Y no no se tarda menos por la última salida aunque lo pueda
> parecer.
> Un enrutador tiene mas criterios que la vía más corta y si cambias
> categorías si que puede que te mande por sitios diferentes. Hay en casos
> que no cambiara y hay en casos que si.
>
> Defiendo que no se hagan cambios sin utilidad y sin sentido. Y que no le
> veo el problema tan grande a como esta pero si veo muchísimos problemas a
> los cambios que comentas. Y no todos los emails los he respondido, alguno
> ni he llegado a leer porque no lo veo tan importante para perder tanto
> tiempo.
>
> Google si que tiene bastante más información que el estado, tiene en
> tiempo real donde estamos y a que velocidad vamos y mucho más. Con lo de
> google estas diciendo lo mismo que yo, que los colores poco importan y no
> es lo que hay que tener en cuenta en el mapa.
>
> OSM da muchos más datos que los colores. Esos datos los tenemos con
> etiquetas de elementos físicos por ejemplo que no tienen nada que ver con
> los colores. No hace falta reinventar la rueda, ya existe. Y como no es una
> Guía Michelín de hace 20 años, por eso los colores no es lo que importa
> como en las guías antiguas.
>
> Un saludo.
>
>
> El sáb., 12 may. 2018 a las 15:43, yo paseopor ()
> escribió:
>
>> Saludos gente,
>>
>> Lo primero que quiero dejar claro es que aunque este debate lo haya
>> iniciado yo no quiero que sea un debate "mío" sobre una propuesta "mía".
>> Por ello he usado documentación oficial. Y aunque yo haya aplicado unos
>> baremos la comunidad puede optar por otros. Tocar las carreteras de medio
>> país no será ni fácil ni debe ser aleatorio. Por ello los criterios los
>> podemos mejorar , especialmente gracias al conocimiento local, que siempre
>> es el que suele tener la última palabra en OSM.
>>
>> 

Re: [Talk-es] Propuesta: cambiar la categoría de algunas carreteras nacionales en base a su uso y estado actuales.

[Diego García]

Sigue sin parecerme bien la propuesta.

Pienso que el valor de la etiqueta highway debe estar referida a toda la
vía, y que hace referencia al nivel de esa vía dentro de la red de vías, no
a sus características físicas. Si se quieren mapear características físicas
de la vía, que pueden cambiar (y de hecho cambian) a lo largo de su
trazado, deben emplearse otras etiquetas: ancho de vía, número de carriles,
velocidad máxima, presencia de arcén,...

En cierto modo, cambiar el valor de la etiqueta highway atendiendo a
criterios físicos, y además por tramos, para que trozos de vías trunk de
peor estado no aparezcan al mismo nivel que otros, sería mapear para el
render.

Un cordial saludo,

El dom., 15 abr. 2018 a las 10:52, yo paseopor ()
escribió:

> Al hilo de una "batalla" (en la que un usuario experimentado me insultó y
> lo dejé por imposible) vuelvo a la carga con un tema simple: la necesidad
> de que toda carretera no transferida y que dependa del Ministerio de
> Fomento del Gobierno de España (nacional) no necesariamente haya de ser
> trunk.
>
> Rationale
>
> Basta con mirar la wiki para darse cuenta de que la definición de trunk no
> encaja con algunas carreteras nacionales en algunos de sus tramos. Además ,
> si miramos a nuestro entorno la cuestión ha cambiado algo desde que lo
> hablamos la última vez, países que habían tenido todas sus carreteras
> "Nacionales/Estatales/..." pintadas de rojo (el color de trunk en OSMCarto)
> ya han distinguido básicamente entre aquellas que son importantes de verdad
> (y que suelen estar desdobladas la gran mayoría) y las que no.Si miramos a
> un zoom 7 no es que nuestros países vecinos se hayan quedado vacíos e
> incomunicados de infraestructuras, es que el render no muestra estas vías
> básicas pero no preferentes hasta el render 8 en que además empiezan a
> mostrarse también las vías de ferrocarril y otras infraestructuras básicas
> que del 8 hacia atrás no salen.
>
> Mirando nuestro entorno vemos que:
>
> Portugal: La clasificación de vías se basa en itinerarios y no en las
> Estradas Nacionais
> Andorra: En Andorra no hay una sola carretera trunk ni siquiera que enlace
> desde otros países...bueno, sí, hay una , adivinad de qué país viene.
> Francia: Hay Routes Nacionales que no lo son.
> Bélgica: No todas las N guardan la misma categoría
> Holanda: Igual caso en Holanda
> Austria: En Austria las B , las que van después de las A, no acostumbran a
> ser trunk.
> Alemania: Mirando un poco por encima veo que las que son trunk son
> aquellas que son autovías.
> Italia: Solo algunas Stradas Stradales son trunk (aún a riesgo de dejarte
> en sus baches las ruedas)
> Suiza: Carreteras principales como la 1 , que atraviesa el país de punta a
> punta no son trunk y el único motivo en general por el que pasarías por
> ellas es para saltarte la viñeta (el impuesto que se paga por acceder a las
> autopistas.)
> Reino Unido: No todas las A son trunk, como tampoco todas sus autovías
> merecieran llamarse así (con semáforos, con rotondas...)
>
> -Tiene sentido también, la gran mayoría de autovías en nuestro país se han
> hecho resiguiendo recorridos de muchas nacionales, cuando no desdoblando la
> misma nacional haciendo desaparecer su trazado original.
> -De igual manera ya hace años por suerte que las vías importantes de cada
> comunidad autónoma que cumplen ciertos requisitos de preferencia (suelen
> ser vías nuevas,fuertes inversiones hechas por estas, sin cruces a nivel,
> con una velocidad que oscila entre los 80 y los 100 km/h y que suelen tener
> un mantenimiento óptimo) ya son consideradas trunk por el mapa y la
> comunidad. ¿Entonces por qué una vía que no cumple con esos mismos
> requisitos debe ser considerada trunk? ¿Simplemente por pertenecer a una
> administración u otra? Aunque suene raro estos días recordemos que todas
> las administraciones son estado (las comunidades autónomas gozan de
> estatutos de autonomía aprobados en el Congreso de los Diputados con rango
> de Ley Orgánica y sancionados por el rey). Por lo que este hecho no debería
> ser significativo para que una vía gozara en el mapa de más o menos
> visibilidad sino que habría que seguir otros criterios más acordes con la
> conducción y el transporte.
>
> -A riesgo de lo antiestético que pueda ser que el mapa quede a trozos...
> ¿es que un buen ruteador no sabe distinguir más allá de la categoría de la
> carretera? ¿Es que nos vamos a fijar en la estética? ¿Es que eso no sería
> mapear para el render? ¿En los otros países en los que eso pasa hay
> problemas para usar navegadores GPS?
>
> -También a riesgo de considerar algunos determinados ejes como de suma
> importancia por el "simple" hecho de reseeguir determinado accidente
> geográfico pensemos en si gozan al lado de una vía alternativa ,aunque esta
> sea de pago (sigue siendo una vía alternativa , y de hecho hoy en día en
> muchas de estas vías hay acuerdos para desviar el tráfico pesado por o que
> su importancia ha 

Re: [Talk-es] Cambio de nombre de calle de Madrid

[Diego García]

A mí me gusta especialmente la etiqueta old_name, porque hasta puede que
nominatim la indexe, sin desmerecer todo lo que hay escrito acerca del
ciclo de vida en la wiki.

Un cordial saludo,

El mié., 28 jun. 2017 10:54, pablo rey  escribió:

> ¿Se guarda en el nombre "caducado" en algún sitio? (además de que quede en
> el historial de cambios). Lo digo porque puede ser útil para los primeros
> tiempos de transición entre nombres.
>
> 2017-06-28 10:38 GMT+02:00 Jesús Lopez :
>
>> Algunos de los nombres ya están cambiados, no sé si todos…
>>
>> Saludos
>>
>> El 28 jun 2017, a las 09:52, Alejandro Moreno 
>> escribió:
>>
>> Hola a todos.
>>
>> Hace un par de meses se aprobó en Madrid el cambio de nombre de varias
>> calles franquistas (
>> http://www.madrid.es/portales/munimadrid/es/Inicio/Actualidad/Noticias/El-Comisionado-de-la-Memoria-Historica-plantea-cambiar-52-calles-en-su-informe-definitivo?vgnextfmt=default=2ce1b707b0fab510VgnVCM201f4a900aRCRD=a12149fa40ec9410VgnVCM10171f5a0aRCRD
>> ). He estado echando un ojo y no parece que se haya realizado el cambio.
>> ¿Hay alguna manera de automatizar esta tarea o hay que hacerla a mano calle
>> por calle y nodo por nodo?
>>
>> Un saludo.
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>>
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Bar tradicional -> ¿ amenity=pub o amenity=bar ?

[Diego García]

Yo no comparto esa forma de verlo, creo necesario e incuestioble que un
mismo valor para un campo tenga el mismo significado en cualquier registro
de una base de datos. Y no veo la necesidad de crear una etiqueta nueva,
con lo que tenemos es suficiente.


Un cordial saludo,



El mar., 20 jun. 2017 a las 20:52, dcapillae ()
escribió:

> La página en inglés para "amenity=bar", en su edición actual (20/06/2017),
> dice que:
>
> «En los países mediterráneos, la palabra "bar" tiene un significado
> diferente (aunque esto no significa necesariamente que la etiqueta deba
> aplicarse de forma diferente). Allí un bar es parte integral del estilo de
> vida. Se va por la mañana a desayunar, en el almuerzo sirven comidas
> sencillas, durante todo el día (si no se cierra después del almuerzo) la
> gente lo usa para tomar un café rápido y por la noche es un lugar de
> encuentro para tomar un aperitivo antes de la cena. Algunos abren por la
> tarde y durante la noche, aunque la mayoría cierran por la noche, algunos
> venden también tabaco, caramelos y sellos. A diferencia de un /pub/, este
> tipo de bar está abierto para el desayuno y el café juega un papel mucho
> más
> importante que la cerveza».
>
> La documentación de la etiqueta invita a usarla indistintamente para bares
> en cualquier parte del mundo. Además, relaciona las diferencias existentes
> en los países mediterráneos con nuestro "estilo de vida", esto es, con
> nuestra cultura y nuestras costumbres. Yo comparto esta forma de verlo, y
> creo que resulta muy útil para resolver problemáticas semejantes con otros
> tipos de etiquetas que estén relacionadas con costumbres culturales.
>
> Sinceramente, no veo la necesidad de crear algo nuevo. Todos sabemos que un
> bar en España es diferente de un bar en Inglaterra. Los ingleses también lo
> saben. Nadie debería extrañarse si al entrar en un local etiquetado con
> "amenity=bar" en España no encuentra el típico bar inglés. Lo contrario
> sería lo extraordinario.
>
>
>
> -
> Daniel Capilla
> OSM user: dcapillae
> --
> View this message in context:
> http://gis.19327.n8.nabble.com/Bar-tradicional-amenity-pub-o-amenity-bar-tp5876448p5898171.html
> Sent from the Spain mailing list archive at Nabble.com.
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Bar tradicional -> ¿ amenity=pub o amenity=bar ?

[Diego García]

Sigue sin ser (para mí) un planteamiento válido.

Lo que hacemos en España en un "amenity=bar" es lo mismo que hacen en el
resto del mundo: tomarnos dos cubatas con los amigos el fin de semana
mientras nos machacan con música de esta que ponen los jóvenes ahora. A mí
me van más los "amenity=pub", donde me tomo una cañita y un par de pinchos
los viernes al salir de trabajar, con los compañeros de trabajo, sin música
ni flautas, y a ser posible sentado, que ya no está el cuerpo como antes.

No hablamos de costumbres, sino del significado de un dato, y ese dato debe
significar lo mismo vayas donde vayas.


Un cordial saludo,



El mar., 20 jun. 2017 a las 19:36, dcapillae ()
escribió:

> Comprendo a qué te refieres, Diego, y me hago cargo del problema. Una
> etiqueta debe referirse inequívocamente a una característica, sin confusión
> posible y siempre la misma para todo el mundo. Del todo razonable.
>
> Ahora bien, algunas características cuestionan esta uniformidad impuesta
> debido a su propia naturaleza o a la imbricación que la propia
> característica tiene respecto a las costumbres o cultura locales. Para las
> funerarias, por ejemplo, existe una única etiqueta (perdón si no estoy en
> lo
> cierto) que se usa indistintamente para funerarias, tanatorios, centro
> conmemorativos de difuntos, etc., de todo el mundo. Las costumbres respecto
> al duelo, sin embargo, pueden ser notablemente distintas en función de la
> cultura y el lugar, y los espacios habilitados para velar al muerto diferir
> notablemente unos de otros según donde nos encontremos.
>
> Si fuese necesario, creo más adecuado utilizar alguna clase de subetiqueta
> que complemente a la etiqueta principal de "amenity=bar".
>
>
>
> -
> Daniel Capilla
> OSM user: dcapillae
> --
> View this message in context:
> http://gis.19327.n8.nabble.com/Bar-tradicional-amenity-pub-o-amenity-bar-tp5876448p5898166.html
> Sent from the Spain mailing list archive at Nabble.com.
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Bar tradicional -> ¿ amenity=pub o amenity=bar ?

[Diego García]

Yo sigo manteniendo la idea que expuso msevilla hace un año. Entre comillas
las etiquetas de OSM "bar" y "pub", para no crear confusión. Cuando hable
de bares españoles lo haré tal cual, sin entrecomillar.

Si se mira la wiki en inglés se puede ver qué significa la etiqueta "bar" y
qué significa la etiqueta "pub" en OSM. La página en español
correspondiente a "bar" no es una traducción de la primera, y la de "pub"
ni siquiera existe. El argumento de que está recogido el significado de bar
en la wiki para la etiqueta "bar" no es válido, porque sólo aparece en la
página española.

Estamos tratando con una base de datos, y en una base de datos el mismo
valor para un campo debe tener el mismo significado en cualquier registro,
eso es incuestionable.

Yo no argumento que para un inglés un "bar" sea un bar de copas. Lo que
digo es que para OSM la etiqueta "bar" *es* un bar de copas.



Un cordial saludo,




El mar., 20 jun. 2017 a las 11:14, dcapillae ()
escribió:

> Comparto esta última línea de opinión: los bares son conocidos como tales
> en
> todo el mundo, lo que los diferencian son las costumbres locales. En una
> conversación vía Telegram comentaba los siguiente:
>
> /No veo la necesidad de crear una etiqueta específica para el bar
> mediterráneo. Los bares ingleses y los bares españoles son esencialmente lo
> mismo, aunque tengan sus diferencias. Las diferencias se dan incluso dentro
> de un mismo país, a nivel regional. Lo que uno espera encontrar en un bar
> de
> Euskadi no lo va a encontrar igual en un bar de Sevilla, por ejemplo. Todos
> son bares, los ingleses, los españoles, los vascos y los sevillanos. Las
> costumbres propias del país crean las diferencias. Entiendo, por tanto, que
> la etiqueta "amenity=bar" junto con la ubicación del bar son suficiente
> para
> saber qué puedes esperar del establecimiento. Si buscas un bar en
> Inglaterra, ya sabes lo que te vas a encontrar, algo ciertamente distinto
> al
> bar español./
>
> Yo dejaría el etiquetado tal como está, no añadiría ninguna etiqueta
> específica para los bares españoles. Así lo hace Wikipedia, por ejemplo,
> tienen una única página donde explican qué es un bar, y recogen en ella sus
> posibles variantes.
>
> Todo el mundo en España sabe, más o menos, lo que puede esperar encontrar
> en
> un local etiquetado con "amenity=bar", al igual que todo el mundo en
> Inglaterra sabe lo que va a encontrar en sus bares. Si se quieren
> documentar
> las particularidades locales de cada país en la página del wiki, me parece
> perfecto, pero no veo la necesidad de crear una etiqueta específica.
>
>
>
> -
> Daniel Capilla
> OSM user: dcapillae
> --
> View this message in context:
> http://gis.19327.n8.nabble.com/Bar-tradicional-amenity-pub-o-amenity-bar-tp5876448p5898150.html
> Sent from the Spain mailing list archive at Nabble.com.
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Tresmiles del Pirineo

[Diego García]

Buenas tardes.

Ahondando en el tema, y ya desde el pc, que resulta más agradecido para
escribir que el móvil, sigo con la historia que dejé colgada en el post
anterior.

Algunos nombres de la lista me estaban sonando a chino, y ayer me tropecé
con el enlace de más abajo. Aunque no comparto el trasfondo político que se
percibe, (porque además esto son mapas, no política), sí estoy de acuerdo
con bastantes de los razonamientos toponímicos que allí se plantean.

Quizá deberíamos darle un giro al tema: propongo poner los nuevos nombres
sólo en official_name, limpiar algunas barbaridades que saltan a la vista
(como el Pico de los Morros), dejar lo demás en paz, y ponernos en contacto
con los clubes de montaña de Huesca y Zaragoza para ver si es posible hacer
una colaboración.

http://www.ordesa.net/foro/viewtopic.php?f=2=61118=cb01a31ed77bc5453377593367c6d352#p61117



Un cordial saludo,



El mar., 13 jun. 2017 a las 22:50, Diego García (<dgerv...@gmail.com>)
escribió:

> Por cierto, que hay para debatir largo y tendido. El gobierno de Aragón la
> ha liado parda con bastantes nombres.
>
> Un cordial saludo,
>
> El mar., 13 jun. 2017 22:32, Diego García <dgerv...@gmail.com> escribió:
>
>> Estamos trabajando en ello...
>>
>> Hay que estudiar el tema del name. No es que hayan sustituido pico por
>> tuca, es que el nombre oficial que han puesto está en aragonés.
>>
>> A falta de más debate, y de reflejarlo en la wiki antes de ponerse a
>> cambiar nada, creo que lo suyo es poner en name la traducción al español de
>> dichos nombres, y poner en name:an los que estén en aragonés.
>>
>> Ojo, porque los picos que hacen frontera con Francia están en bilingüe.
>> En cualquier caso, no habría que tocar el resto de etiquetas name.
>>
>> Un cordial saludo,
>>
>> El mar., 13 jun. 2017 22:24, Uranzu <aguirrera...@gmail.com> escribió:
>>
>>> Hola,
>>>
>>> Supongo que los aragoneses estaréis bien enterados de que el Gobierno de
>>> Aragón ha cambiado los nombres de casi todos los tresmiles del Pirineo
>>> [1] y
>>> ha publicado un mapa [2] con el detalle. Por de pronto la palabra “pico”
>>> casi desaparece para convertirse en “tuca”. Por ejemplo, el Pico Aneto
>>> pasa
>>> a ser la “Tuca d'Aneto / Maladeta de Corones”.
>>>
>>> Dejando de lado el que nos guste o dejar de gustar este cambio (ha creado
>>> bastante polémica) me surgen algunas dudas técnicas:
>>>
>>> 1. ¿Creéis que deberían incorporarse los nuevas topónimos a
>>> Openstreetmap?
>>> ¿Hay que esperar a alguna publicación oficial?
>>>
>>> 2. ¿Habría que pedir permiso al susodicho Gobierno de Aragón o con la
>>> presentación y publicación en publico se sobreentiende que es de dominio
>>> público?
>>>
>>> 3. ¿Qué etiqueta deberíamos usar? Cambiar la etiqueta “name=” me parece
>>> muy
>>> fuerte. Mirando en la wiki parece que “offical_name=” es la adecuada
>>> pero si
>>> tenemos en cuenta que muchos de los picos hacen frontera con Francia
>>> opino
>>> que igual mejor “official_name:es=”
>>>
>>> 4. No hay que mapear para el render, lo sé, pero me temo que si ponemos
>>> los
>>> 160 tresmiles , siendo muchos de ellos cimas secundarias podrían quedar
>>> tapados los picos principales y no veo en la wiki una etiqueta que
>>> permita
>>> diferenciarlos...
>>>
>>> Un saludo
>>>
>>> [1] http://aragondocumenta.com/proyecto-tresmiles/
>>> [2]
>>> http://aragonhoy.aragon.es/index.php/mod.noticias/mem.detalle/id.199625
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://gis.19327.n8.nabble.com/Tresmiles-del-Pirineo-tp5897892.html
>>> Sent from the Spain mailing list archive at Nabble.com.
>>>
>>> ___
>>> Talk-es mailing list
>>> Talk-es@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-es
>>>
>>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Tresmiles del Pirineo

[Diego García]

Por cierto, que hay para debatir largo y tendido. El gobierno de Aragón la
ha liado parda con bastantes nombres.

Un cordial saludo,

El mar., 13 jun. 2017 22:32, Diego García <dgerv...@gmail.com> escribió:

> Estamos trabajando en ello...
>
> Hay que estudiar el tema del name. No es que hayan sustituido pico por
> tuca, es que el nombre oficial que han puesto está en aragonés.
>
> A falta de más debate, y de reflejarlo en la wiki antes de ponerse a
> cambiar nada, creo que lo suyo es poner en name la traducción al español de
> dichos nombres, y poner en name:an los que estén en aragonés.
>
> Ojo, porque los picos que hacen frontera con Francia están en bilingüe. En
> cualquier caso, no habría que tocar el resto de etiquetas name.
>
> Un cordial saludo,
>
> El mar., 13 jun. 2017 22:24, Uranzu <aguirrera...@gmail.com> escribió:
>
>> Hola,
>>
>> Supongo que los aragoneses estaréis bien enterados de que el Gobierno de
>> Aragón ha cambiado los nombres de casi todos los tresmiles del Pirineo
>> [1] y
>> ha publicado un mapa [2] con el detalle. Por de pronto la palabra “pico”
>> casi desaparece para convertirse en “tuca”. Por ejemplo, el Pico Aneto
>> pasa
>> a ser la “Tuca d'Aneto / Maladeta de Corones”.
>>
>> Dejando de lado el que nos guste o dejar de gustar este cambio (ha creado
>> bastante polémica) me surgen algunas dudas técnicas:
>>
>> 1. ¿Creéis que deberían incorporarse los nuevas topónimos a Openstreetmap?
>> ¿Hay que esperar a alguna publicación oficial?
>>
>> 2. ¿Habría que pedir permiso al susodicho Gobierno de Aragón o con la
>> presentación y publicación en publico se sobreentiende que es de dominio
>> público?
>>
>> 3. ¿Qué etiqueta deberíamos usar? Cambiar la etiqueta “name=” me parece
>> muy
>> fuerte. Mirando en la wiki parece que “offical_name=” es la adecuada pero
>> si
>> tenemos en cuenta que muchos de los picos hacen frontera con Francia opino
>> que igual mejor “official_name:es=”
>>
>> 4. No hay que mapear para el render, lo sé, pero me temo que si ponemos
>> los
>> 160 tresmiles , siendo muchos de ellos cimas secundarias podrían quedar
>> tapados los picos principales y no veo en la wiki una etiqueta que permita
>> diferenciarlos...
>>
>> Un saludo
>>
>> [1] http://aragondocumenta.com/proyecto-tresmiles/
>> [2]
>> http://aragonhoy.aragon.es/index.php/mod.noticias/mem.detalle/id.199625
>>
>>
>>
>> --
>> View this message in context:
>> http://gis.19327.n8.nabble.com/Tresmiles-del-Pirineo-tp5897892.html
>> Sent from the Spain mailing list archive at Nabble.com.
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Tresmiles del Pirineo

[Diego García]

Estamos trabajando en ello...

Hay que estudiar el tema del name. No es que hayan sustituido pico por
tuca, es que el nombre oficial que han puesto está en aragonés.

A falta de más debate, y de reflejarlo en la wiki antes de ponerse a
cambiar nada, creo que lo suyo es poner en name la traducción al español de
dichos nombres, y poner en name:an los que estén en aragonés.

Ojo, porque los picos que hacen frontera con Francia están en bilingüe. En
cualquier caso, no habría que tocar el resto de etiquetas name.

Un cordial saludo,

El mar., 13 jun. 2017 22:24, Uranzu  escribió:

> Hola,
>
> Supongo que los aragoneses estaréis bien enterados de que el Gobierno de
> Aragón ha cambiado los nombres de casi todos los tresmiles del Pirineo [1]
> y
> ha publicado un mapa [2] con el detalle. Por de pronto la palabra “pico”
> casi desaparece para convertirse en “tuca”. Por ejemplo, el Pico Aneto pasa
> a ser la “Tuca d'Aneto / Maladeta de Corones”.
>
> Dejando de lado el que nos guste o dejar de gustar este cambio (ha creado
> bastante polémica) me surgen algunas dudas técnicas:
>
> 1. ¿Creéis que deberían incorporarse los nuevas topónimos a Openstreetmap?
> ¿Hay que esperar a alguna publicación oficial?
>
> 2. ¿Habría que pedir permiso al susodicho Gobierno de Aragón o con la
> presentación y publicación en publico se sobreentiende que es de dominio
> público?
>
> 3. ¿Qué etiqueta deberíamos usar? Cambiar la etiqueta “name=” me parece muy
> fuerte. Mirando en la wiki parece que “offical_name=” es la adecuada pero
> si
> tenemos en cuenta que muchos de los picos hacen frontera con Francia opino
> que igual mejor “official_name:es=”
>
> 4. No hay que mapear para el render, lo sé, pero me temo que si ponemos los
> 160 tresmiles , siendo muchos de ellos cimas secundarias podrían quedar
> tapados los picos principales y no veo en la wiki una etiqueta que permita
> diferenciarlos...
>
> Un saludo
>
> [1] http://aragondocumenta.com/proyecto-tresmiles/
> [2]
> http://aragonhoy.aragon.es/index.php/mod.noticias/mem.detalle/id.199625
>
>
>
> --
> View this message in context:
> http://gis.19327.n8.nabble.com/Tresmiles-del-Pirineo-tp5897892.html
> Sent from the Spain mailing list archive at Nabble.com.
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[Talk-es] Sobre cañones deportivos (barranquismo)

[Diego García]

Buenas tardes a todos.

En respuesta a una pregunta planteada por otro usuario en el canal de
Telegram, hago una aclaración sobre la forma de etiquetar barrancos
deportivos en OSM. No es una propuesta, sino un desarrollo lógico de lo que
ya tenemos en uso sobre etiquetado de rutas deportivas en OSM, sin ánimo en
absoluto de sentar cátedra sobre el asunto. Sólo pretendo ayudar y, por
supuesto, estoy abierto a escuchar cualquier otra opinión.

La forma de etiquetar una ruta deportiva, por ejemplo de senderismo, es
agrupar todos los tramos de dicha ruta en una relación, etiquetada a
continuación como *type=route* y *route=hiking*, junto con la
correspondiente etiqueta *name*. Para este ejemplo concreto existen otras
etiquetas, como *osmc:symbol* o *network*, pero no vienen al caso de los
barrancos. Lo básico son las etiquetas *type *y *route*.

Un barranco deportivo debería seguir la misma pauta: agrupar los tramos
deportivos de dicho barranco en una relación, y definir la relación
conseguida como *type=route*. Para especificar más el tipo de ruta no hay
un tag aprobado, pero pienso que puede (y debe) usarse el propuesto en la
wiki http://wiki.openstreetmap.org/wiki/Proposed_features/Canyoning
*route=canyoning*. Allí también se propone, con acierto pienso yo, el
tag *rating
*para definir la dificultad del barranco. Quizá necesitaría algún otro tag:
es muy común en los barrancos indicar siempre el número de rápeles que hay
que hacer, así como la longitud del rápel más largo.

Lo que resulta incorrecto es agrupar TODOS los barrancos de un área
determinada, por ejemplo una provincia, en una misma relación. Debe haber
una relación por cada barranco. Si se quieren obtener los barrancos
deportivos de una zona determinada, debe utilizarse overpass. Tampoco es
correcto cambiar el *name *a un tramo de río/barranco con el nombre con que
se conoce deportivamente ese tramo, o incluir etiquetas en la relación como
*intermittent=yes*, *waterway *o *sport*.

Como ejemplo, acabo de subir un cambio sacando de la relación "Barrancos
deportivos de la provincia" (que no era tal sino una colección de
elementos, lo que es incorrecto), el tramo deportivo del río Flumen
conocido como Barranco de las Palomeras del Flumen. Puede verse aquí:
http://www.openstreetmap.org/changeset/47446273 No he incluído el tag *rating
*porque no conozco la dificultad correcta de dicho barranco (sé que es
jodidillo por la cantidad de agua que lleva, es un río al fin y al cabo,
pero no lo he bajado personalmente). Sirva de sencillo ejemplo.

Idem para el tema "vías ferratas". Que un sendero sea una vía ferrata es
una condición de un tramo de dicho sendero, no da pié a definir una
relación. La etiqueta que define la vía ferrata debe ir en el tramo que es
vía ferrata, y si se crea una relación (p.ej tipo *hiking*) para definir la
ruta, no debe contener etiquetas de dicho tipo, ya que no toda la ruta es
vía ferrata. Las relaciones del tipo "Conjunto de vías ferratas de la
provincia", son incorrectas.

Espero que esto haya aclarado las dudas, y estaría bien ver algún otro
aporte sobre el tema por aquí.


Un saludo,
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Puntos de comercios en la línea de los edificios

[Diego García]

Para mí, dentro del polígono, sin duda. Coge la addr sin problemas, y no da
lugar a dudas o excepciones a la regla, por ejemplo comercios interiores o
con distinta addr que el edificio principal, o edificios colindantes.

Además, resulta más estético y claro una vez renderizado en el mapa.

Un saludo,

El jue., 23 mar. 2017 11:45, Alejandro S.  escribió:

> Buenas,
>
> Parece que no hay consenso, ni con los portales ni con los POIs:
> * Ahí [0] dice que (para los portales) se puede poner el nodo en el borde
> o dentro del polígono:
> * Aquí [1] señala (para un caso concreto de POI) que se ponga un nodo en
> el interior del área.
>
> Además si el nodo se sitúa en el perímetro, puede dar lugar a error en
> caso de que haya áreas colindantes.
>
>
> [0]:
> https://wiki.openstreetmap.org/wiki/Addresses#Buildings_with_multiple_house_numbers
> [1]:
> https://wiki.openstreetmap.org/wiki/Tag:amenity=cafe#Cafes_inside_other_shops_.2F_amenities
>
>
> Atentamente,
>   Alejandro Suárez
>
> 2017-03-23 11:14 GMT+01:00 Miguel Sevilla-Callejo :
>
> Hola,
>
> Corto/pego aquí una discusión muy interesante que ha surgido en el grupo
> de Telegram/Riot a cerca de si los puntos de los comercios han de ir en la
> línea de los edificios y no en su interior.
>
> Oscar Zorrilla Alonso, [22.03.17 22:21]
>
> Hola chicos, os presentamos el municipio de Miranda de Ebro, realizado por
> elpata33 [...] el tío es productivo para OSM.
>
> Mirad los pois metidos:
> http://www.openstreetmap.org/#map=17/42.68572/-2.94171
>
> Carlos Tapia, [22.03.17 22:31]
> Ahora sólo falta que los nodos de los comercios formen parte del polígono
> y no dejarlos sueltos dentro
>
> Nunca se debe dejar un nodo de un comercio suelto dentro de un polígono,
> normas básicas y fundamentales de OSM
>
> Y los números de portal más de lo mismo
>
> [...]
>
> Jorge Sanz, [22.03.17 23:16] / [In reply to Oscar Zorrilla Alonso]
> Yo habia visto hace unos días que estaba haciendo cosas por Miranda de
> Ebro pero no habia visto que habia tanto POI o no los habia puesto todavia.
> Se lo curra
>
> [...]
>
> Alejandro S., [23.03.17 10:04] / [In reply to Carlos Tapia]
> ¿Me podrías pasar las referencias a esto?
>
> Carlos Tapia, [23.03.17 10:05]
> Hay varios hilos de mensajes a esto en Telegram y por la lista de correo
>
> Alejandro S., [23.03.17 10:06]
> No me suena haberlo leído en la plataforma de documentación de
> OpenStreetMap
>
> Miguel Sevilla-Callejo, [23.03.17 10:07] / [In reply to Oscar Zorrilla
> Alonso]
> Wow! pero a ver quien mantiene actualizada toda esa información ahora 
>
> [...]
>
> Miguel Sevilla-Callejo, [23.03.17 10:11] / [In reply to Carlos Tapia]
> De todos modos por el resto del mundo sulene estar sueltos. ¿hay mención
> explícita a esto en la wiki?
>
> Miguel Sevilla-Callejo, [23.03.17 10:11]
> Si que hablamos lo de los portales pero no lo de los comercios... aunque
> tiene su paralelismo, si.
>
> [...]
>
> Jorge Sanz, [23.03.17 10:11]
> Con numeros de portal si pero con los comercios yo no tengo tan claro eso
> de que se tenga que ponerse en la vía del edificio
>
> Carlos Tapia, [23.03.17 10:11]
> Exceptuando en centros comerciales que por ser comercios interiores es
> imposible. Todos los comercios deben ser un nodo EN el edificio, no dentro
> de él. De esta forma coge la información de la dirección del polígono y no
> hay que volver a incluirla. Además de que queda más homogéneo y más
> completo.
>
> Los números de portal se pueden incluir en el polígono o añadir la
> dirección para todo el área, pero incluyendo la entrada para saber dónde
> está físicamente la entrada
>
> Jorge Sanz, [23.03.17 10:12]
> Si esta dentro coge exactamente igual el nombre de la dirección
>
> Alejandro S., [23.03.17 10:13] / [In reply to Jorge Sanz]
> Eso es, es una operación que la base de datos geoespacial realiza
> fácilmente
>
> Carlos Tapia, [23.03.17 10:13]
> Pero si está dentro y sigues las normas de los portales se debería poner
> donde está la entrada a ese comercio. Si lo pones en la fachada eso que te
> ahorras
>
> Carlos Tapia, [23.03.17 10:14]
> Es más útil saber por donde se entra a un comercio que saber sólo que está
> por ahí
>
> Alejandro S., [23.03.17 10:15] / [In reply to Carlos Tapia]
> De acuerdo, pero eso está documentado en algún sitio o te lo estás sacando
> de la manga @carlosz22?
>
> Carlos Tapia, [23.03.17 10:16]
> Ni idea de si está documentado
>
> Jorge Sanz, [23.03.17 10:16]
> Al menos de que este en algun sitio claro que la comunidad ha dicho que
> tenga que lo correcto ya dicho que se ponga tambien en la vía, se debería
> discutir en la lista.
>
> ---
>
> Abierto el debate en la lista!!
>
> Hasta donde yo se no hemos dejado claro aquí, ni se ha consensuado a nivel
> golbal (en la wiki) como proceder al respeto de la integración del los
> nodos de comercios si existen polígonos/areas/relaciones para los edificios.
>
> Lo que sugiere Carlos tiene su lógica, pero no se si hemos de proceder así.
>

Re: [Talk-es] Bienes de Interés Cultural en España

[Diego García]

Buenas tardes, Daniel.

Llevo un par de días estudiando el tema (era uno de esos proyectos que
tengo siempre pendientes, meter los bic de mi zona), y me queda una duda
sobre el etiquetado descrito en la wiki: ¿no crees que son redundantes las
etiquetas protection_title:category y bic:criteria?




Un saludo,

El dom., 5 mar. 2017 a las 18:39, dcapillae ()
escribió:

> Gracias, Manu. Precisamente tengo enlazada la página de Wikipedia sobre
> Bienes de Interés Cultural a la página dedicada a Málaga en el OSM Wiki.
>
> En Wikipedia hay mucho y muy buen trabajo ya realizado. En OpenStreetMap
> queda todavía mucho por hacer. Yo abarco más bien poco, me intereso casi
> exclusivamente por el municipio de Málaga, y no en todos sus aspectos en lo
> que concierne a OpenStreetMap. Aún así, entiendo que debemos mantener el
> mismo criterio de etiquetado en los BIC de toda España. La documentación de
> la clave  ref:bic 
> pretende ser eso, una página de referencia sobre cómo se etiquetan.
>
>
>
>
> -
> Daniel Capilla
> OSM user: dcapillae
> --
> View this message in context:
> http://gis.19327.n8.nabble.com/Bienes-de-Interes-Cultural-en-Espa-a-tp5892400p5892469.html
> Sent from the Spain mailing list archive at Nabble.com.
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Importación de la red básica de transporte de agua de Tenerife

[Diego García]

Si los cauces para drenaje (doy por supuesto que excavados por el hombre,
sino no serían waterway drain), sirven para evacuar el agua de lluvia y/o
el exceso de riego, es decir, no llevan agua continuamente, valora incluir
también la etiqueta intermittent=yes.


Un saludo,

El lun., 6 mar. 2017 a las 10:28, Javier Sánchez Portero (<
javiers...@gmail.com>) escribió:

> En mi caso, históricamente, se usaban tanto para riego como para
> abastecimiento. Actualmente el consumo humano se ha pasado a conducciones
> cerradas por seguridad.
>
> El 6 de marzo de 2017, 9:12, Javier Sánchez Portero 
> escribió:
>
> Estoy de acuerdo, cambio la propuesta para usar esa etiqueta en la
> importación y modifico todos los canales que están actualmente dibujados en
> la isla.
>
> Voy a ver si puedo traducir la entrada en la wiki de la etiqueta ditch y
> habría que poner alguna anotación en Normalización para evitar futuras
> confusiones.
>
> Overpass da 1934 vías (y 7 polígonos ¿?) para waterway:drain and name=* in
> Spain y 3192 vías (y 1 polígono) para la misma consulta con ditch.
>
> El 6 de marzo de 2017, 6:45, David Marín Carreño 
> escribió:
>
> No es lo mismo un drain que un ditch.
>
> Drain es una conducción de agua de drenaje. Se usa para canalizar y drenar
> el agua de lluvia.
>
> Acequia es 'irrigation ditch' en inglés, los que podría traducirse
> textualmente como "zanja de regadío".
>
> No conozco el caso de Tenerife, pero si estamos hablando de acequias de
> regadío yo no usaría drain sino ditch.
>
> Un saludo
> --
> David
>
> El lun., 6 mar. 2017 1:40, Javier Sánchez Portero 
> escribió:
>
> Hola
>
> Comunico para su debate el segundo proyecto de importación relacionado con
> el Plan Hidrológico de Tenerife que tengo previstos.
>
> <
> https://wiki.openstreetmap.org/wiki/ES:Import_of_Tenerife%27s_basic_water_transport_network
> >
>
> Me gustaría contar con vuestras aportaciones y sugerencias para poder
> dirigirme luego a la lista imports.
>
> He elegido como etiqueta para los canales (acéquias) waterway=drain, que
> es la que actualmente se está usando en la isla. En otros lugares de España
> se está usando waterway=ditch y según Overpass se usa más aunque hay muchas
> apariciones de ambas.
>
> Saludos, Javier Sánchez
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Dehesas

[Diego García]

En mi opinión, al ser un tipo de bosque degradado y estar explotados por el
hombre, son más landuse forest que natural wood. Apuesto por lo primero.

En cualquier caso, es cuestión de mirar si cumple las condiciones de bosque
por densidad de árboles.

¿Qué dice SIOSE?

Un saludo,

El jue., 2 mar. 2017 15:48, Gabriel Rodríguez Alberich 
escribió:

> Hola a todos.
>
> Me entra la duda de cómo etiquetar las zonas de dehesa, porque son
> espacios algo especiales que están a medio camino entre un bosque, pasto
> para ganado y cultivo (ni del todo landuse:forest ni del todo
> landuse:farmland).
>
> Ya he visto que hay un buen cacao solo para el caso de los bosques [1],
> pero en este caso también haría falta significar que sufren explotación
> ganadera y agrícola. También he buscado en los archivos, pero creo que
> nunca se ha discutido en la lista.
>
> ¿Tenéis alguna sugerencia de cómo modelar esto?
>
> [1] http://wiki.openstreetmap.org/wiki/Forest#Which_tag_should_be_used.3F
>
> --
> Gabriel Rodríguez Alberich
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Proposed_features/Extended_traffic_signs_tagging

[Diego García]

Buenas tardes a todos.


En líneas generales a mí me parece correcto. Puntos que querría destacar:

- Es compatible con el etiquetado actual, no obliga a cambiar lo que ya
está etiquetado.

- La notación para separar valores múltiples propuesta me parece genial,
totalmente correcta respecto al punto y coma. Ojalá se adoptara para el
resto de ejemplos con los que peleamos de vez en cuando.

- En la parte dedicada a señales informativas de destino, no acabo de
entender el esquema general. En parte porque no domino lo que tenemos
actualmente, para poder comparar, y en parte porque le tengo manía al
inglés.

- La información de rotondas es bastante compleja, pero es que quizá no
haya otra forma tan esquemática de hacerlo. En este punto se hace necesario
alguna ayuda en forma de plugin de JOSM para etiquetar.

En resumen, desde el momento en que no es incompatible con el etiquetado
actual, sino que añade posibilidades, creo que debería seguir adelante.
Quizá haya que pulir puntos y simplificar algún esquema, de cara a su
comprensión y legibilidad, pero no ser rechazado.



Un saludo,

_

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

Re: [Talk-es] Fusión de municipios

[Diego García]

Por cierto, que he visto que alguien ha definido el landuse residential de
Cerdedo como outer de un multipolígono etiquetado como:

name=Cerdedo
place=county
population=Cerdedo

y como inner un trozo alrededor de la iglesia del pueblo. Como mínimo, me
parece una edición algo dudosa.



Un saludo,


El lun., 6 feb. 2017 a las 18:25, Diego García (<dgerv...@gmail.com>)
escribió:

> Buenas tardes, Jesús.
>
> En realidad, si todo está ahora mismo bien hecho, es sencillo. Te aconsejo
> que utilices el JOSM para todo esto.
>
> La cabecera del nuevo municipio pasará a Cotobade, por lo que lo suyo es
> mantener la relación boundary de Cotobade. Entre los dos antiguos
> municipios sólo hay una vía (la 45341181), por lo que lo mejor es
> eliminarla, con lo que desaparecerá de las dos relaciones. A continuación
> edita la relación de Cotobade, añadiendo vías a partir del hueco dejado por
> la que has quitado, siguiendo el límite de Cerdedo (vías 45341272, 45341110
> y 45341195), y ponle a todas el rol outer. Cuando la hayas completado
> recuerda añadir el nodo de A Chan a la relación, con rol admin_centre
> (ahora mismo no hay ningún nodo, y debería haberlo). Y por supuesto, cambia
> el name de la relación por "Cerdedo-Cotobade".
>
> Por último, ya puedes eliminar la relación de Cerdedo. Respecto a la
> relación padre (Pontevedra), se seguirá manteniendo la jerarquía sin
> problemas, porque no estás eliminando la relación Cotobade, que ya es hija
> de la relación Pontevedra.
>
> Hazlo todo en un mismo changeset, sin tocar nada más en él, por si se
> rompe algo poder dar marcha atrás con facilidad. En el source de ese
> changeset lo suyo sería poner el enlace al BOE que recoge este cambio.
>
>
>
> Un saludo,
>
>
>
>
> El lun., 6 feb. 2017 a las 16:25, Jesús Lopez (<jesusl.te...@gmail.com>)
> escribió:
>
> Buenas tardes. El pasado día 27 el Boletín Oficial del Estado [1] publicó
> de forma definitiva la aprobación de la fusión de los municipios de Cerdedo
> y Cotobade en un nuevo ayuntamiento que se denomina Cerdedo-Cotobade y el
> Instituto Nacional de Estadística [2] también se ha adaptado ya a la nueva
> denominación. En OSM aún figuran ambos de forma independiente y me gustaría
> consultaros como se puede abordar el proceso para reflejar este cambio.
> ¿Simplemente borramos la frontera entre ambos y adoptamos la nueva
> denominación o hay que tener en cuenta otras relaciones?. Espero vuestra
> ayuda,
>
> Saludos.
> Jesús
>
> ——
> [1] http://boe.es/boe/dias/2017/01/27/pdfs/BOE-A-2017-898.pdf
> [2] http://www.ine.es/daco/daco42/codmun/codmunmod.htm
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Fusión de municipios

[Diego García]

Buenas tardes, Jesús.

En realidad, si todo está ahora mismo bien hecho, es sencillo. Te aconsejo
que utilices el JOSM para todo esto.

La cabecera del nuevo municipio pasará a Cotobade, por lo que lo suyo es
mantener la relación boundary de Cotobade. Entre los dos antiguos
municipios sólo hay una vía (la 45341181), por lo que lo mejor es
eliminarla, con lo que desaparecerá de las dos relaciones. A continuación
edita la relación de Cotobade, añadiendo vías a partir del hueco dejado por
la que has quitado, siguiendo el límite de Cerdedo (vías 45341272, 45341110
y 45341195), y ponle a todas el rol outer. Cuando la hayas completado
recuerda añadir el nodo de A Chan a la relación, con rol admin_centre
(ahora mismo no hay ningún nodo, y debería haberlo). Y por supuesto, cambia
el name de la relación por "Cerdedo-Cotobade".

Por último, ya puedes eliminar la relación de Cerdedo. Respecto a la
relación padre (Pontevedra), se seguirá manteniendo la jerarquía sin
problemas, porque no estás eliminando la relación Cotobade, que ya es hija
de la relación Pontevedra.

Hazlo todo en un mismo changeset, sin tocar nada más en él, por si se rompe
algo poder dar marcha atrás con facilidad. En el source de ese changeset lo
suyo sería poner el enlace al BOE que recoge este cambio.



Un saludo,




El lun., 6 feb. 2017 a las 16:25, Jesús Lopez ()
escribió:

> Buenas tardes. El pasado día 27 el Boletín Oficial del Estado [1] publicó
> de forma definitiva la aprobación de la fusión de los municipios de Cerdedo
> y Cotobade en un nuevo ayuntamiento que se denomina Cerdedo-Cotobade y el
> Instituto Nacional de Estadística [2] también se ha adaptado ya a la nueva
> denominación. En OSM aún figuran ambos de forma independiente y me gustaría
> consultaros como se puede abordar el proceso para reflejar este cambio.
> ¿Simplemente borramos la frontera entre ambos y adoptamos la nueva
> denominación o hay que tener en cuenta otras relaciones?. Espero vuestra
> ayuda,
>
> Saludos.
> Jesús
>
> ——
> [1] http://boe.es/boe/dias/2017/01/27/pdfs/BOE-A-2017-898.pdf
> [2] http://www.ine.es/daco/daco42/codmun/codmunmod.htm
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Error en etiquetado de vértices geodésicos importados del IGN

[Diego García]

Por supuesto, hacerlo todo de golpe es mejor, teniendo en cuenta la
cantidad de nodos que hay. Eso no lo permite osmose.

Un saludo

El dom., 5 feb. 2017 20:51, Carlos Dávila <cdavi...@orangecorreo.es>
escribió:

> Con osmose se pueden editar de golpe o hay que ir uno por uno? Yo ayer
> empecé a corregir en JOSM hasta que me dio por mirar los números y al
> ver la cantidad me pareció absurdo hacerlo a mano, cuando se puede hacer
> en menos de un minuto.
> A mi las etiquetas que hay tampoco me parece necesario eliminarlas
>
> El 05/02/17 a las 20:35, Diego García escribió:
> >
> > Escribo desde el móvil, no me extenderé mucho.
> >
> > El error de la etiqueta ele lo detecta osmose, y se arregla fácilmente
> > desde allí. Los que están reparados alrededor de Huesca se han editado
> > de esa manera.
> >
> > El resto de etiquetas yo las conservaría. Los vértices pueden
> > pertenecer a distintas redes, y además tienen una referencia de forma
> > que se puede localizar información en IGN rápidamente, y que los
> > identifica. Normalmente estoy en contra de poner o mantener
> > información innecesaria o redundante, pero en este caso lo veo útil.
> >
> > Un saludo,
> >
> >
> > El dom., 5 feb. 2017 18:54, Carlos Dávila <cdavi...@orangecorreo.es
> > <mailto:cdavi...@orangecorreo.es>> escribió:
> >
> > Hola
> >
> > Ayer me di cuenta de que los vértices geodésicos que se importaron
> del
> > IGN en 2012 tienen varios errores en la etiqueta "ele". Por un
> > lado, se
> > usa la coma como separador decimal, lo que es contrario a la norma
> > general en OSM, y por otro tienen como unidad " m.". En OSM las
> > alturas,
> > como otras magnitudes, tienen una unidad predeterminada, metros en
> > este
> > caso, por lo que no se debe indicar la unidad salvo que sea
> > distinta de
> > la predeterminada, y en todo caso no debería llevar punto después
> > de la
> > m. Aunque algunos nodos ya han sido corregidos (una zona amplia
> > alrededor de Salamanca y Huesca básicamente), la gran mayoría siguen
> > igual que se importaron, concretamente 8.546 de 9.690.
> >
> > Estos errores se pueden corregir fácilmente con un poco de
> > buscar/reemplazar, pero como eso es una edición automatizada hay que
> > seguir las directrices indicadas en [1] y por eso lo comento aquí,
> > para
> > que se debata en la lista. He creado la página [2] en la wiki
> > describiendo el proceso propuesto.
> >
> > Otro error que había es que hay vértices que tienen dos valores en la
> > altura, uno entero y otro decimal, separados por punto y coma, por
> > ejemplo "1527;1527.12". Como esos eran pocos los he corregido a mano
> > dejando el valor más preciso, salvo un par de ellos en los que no
> > coinciden los dos valores.
> >
> > Como recientemente se comentó la posibilidad/conveniencia de eliminar
> > algunas etiquetas innecesarias de objetos importados, quizá se
> pudiera
> > aprovechar la ocasión para hacerlo. Estas son las etiquetas de la
> > importación que contienen los vértices geodésicos:
> >
> >   * ign:latitud (en mi opinión se debería mantener, el valor es más
> > preciso que el que tienen los objetos de OSM).
> >   * ign:longitud (idem).
> >   * ign:red
> >   * source:ref
> >   * ref: supongo que es una referencia interna usada por el IGN, no
> > utilizada de forma general.
> >
> > [1]
> https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
> >
> > [2]https://wiki.openstreetmap.org/wiki/Automated_Edits/cdavila
> >
> >
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Error en etiquetado de vértices geodésicos importados del IGN

[Diego García]

Escribo desde el móvil, no me extenderé mucho.

El error de la etiqueta ele lo detecta osmose, y se arregla fácilmente
desde allí. Los que están reparados alrededor de Huesca se han editado de
esa manera.

El resto de etiquetas yo las conservaría. Los vértices pueden pertenecer a
distintas redes, y además tienen una referencia de forma que se puede
localizar información en IGN rápidamente, y que los identifica. Normalmente
estoy en contra de poner o mantener información innecesaria o redundante,
pero en este caso lo veo útil.

Un saludo,

El dom., 5 feb. 2017 18:54, Carlos Dávila 
escribió:

> Hola
>
> Ayer me di cuenta de que los vértices geodésicos que se importaron del
> IGN en 2012 tienen varios errores en la etiqueta "ele". Por un lado, se
> usa la coma como separador decimal, lo que es contrario a la norma
> general en OSM, y por otro tienen como unidad " m.". En OSM las alturas,
> como otras magnitudes, tienen una unidad predeterminada, metros en este
> caso, por lo que no se debe indicar la unidad salvo que sea distinta de
> la predeterminada, y en todo caso no debería llevar punto después de la
> m. Aunque algunos nodos ya han sido corregidos (una zona amplia
> alrededor de Salamanca y Huesca básicamente), la gran mayoría siguen
> igual que se importaron, concretamente 8.546 de 9.690.
>
> Estos errores se pueden corregir fácilmente con un poco de
> buscar/reemplazar, pero como eso es una edición automatizada hay que
> seguir las directrices indicadas en [1] y por eso lo comento aquí, para
> que se debata en la lista. He creado la página [2] en la wiki
> describiendo el proceso propuesto.
>
> Otro error que había es que hay vértices que tienen dos valores en la
> altura, uno entero y otro decimal, separados por punto y coma, por
> ejemplo "1527;1527.12". Como esos eran pocos los he corregido a mano
> dejando el valor más preciso, salvo un par de ellos en los que no
> coinciden los dos valores.
>
> Como recientemente se comentó la posibilidad/conveniencia de eliminar
> algunas etiquetas innecesarias de objetos importados, quizá se pudiera
> aprovechar la ocasión para hacerlo. Estas son las etiquetas de la
> importación que contienen los vértices geodésicos:
>
>   * ign:latitud (en mi opinión se debería mantener, el valor es más
> preciso que el que tienen los objetos de OSM).
>   * ign:longitud (idem).
>   * ign:red
>   * source:ref
>   * ref: supongo que es una referencia interna usada por el IGN, no
> utilizada de forma general.
>
> [1]https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
>
> [2]https://wiki.openstreetmap.org/wiki/Automated_Edits/cdavila
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Reflexiones y propuestas para la OSM-es tras mi paso por la wiki

[Diego García]

Gracias Santiago.

Me he limitado a añadir dos puntos:


   - Creación de un grupo de trabajo dedicado a dinamizar y potenciar la
   wiki en particular, designando a alguien como coordinador de dichos
   esfuerzos.
   - Si dicho grupo sale adelante, creación de una sala en Riot o similar
   para debatir/informar sobre la wiki, sin saturar otros canales.


Con eso es más que suficiente. Si sale adelante el grupo, sería el momento
de que éste determinase si las actuaciones de Verdy_p pueden ser o no un
elemento que desanime a gente que quiera aportar contenido a la wiki.

Muchas gracias de nuevo, un saludo,

Diego


El lun., 16 ene. 2017 a las 13:29, Santiago Crespo (<
openstreet...@flanera.net>) escribió:

> Hola Diego, gracias por el curro.
>
> Sobre tratar estos dos temas en la próxima reunión, por favor añádelos
> aquí:
>
> http://osm.org/wiki/ES:Orden_del_día_siguiente_reunión_OSM-ES
>
> Saludos,
> Santiago Crespo
>
> On 01/15/2017 09:23 PM, Diego García wrote:
> > - En primer lugar, *afianzar un grupo dedicado a poner orden en la parte
> > española de la wiki, con una cabeza pensante que coordine esfuerzos* (ó
> > dinamizador, que es como se dice en las reuniones de la OSM-es  ;-)  ).
> > Esto ya se decidió en la primera reunión de la asociación,
> > https://wiki.openstreetmap.org/wiki/ES:Acta_20160906 , pero no quedó muy
> > claro el asunto, y no se especificó un grupo para la wiki, y pienso que
> > es importante sentar la bases de un grupo propio desde YA. He visto
> > pinceladas importantes, (organización del Wikiproyecto España, p.ej.),
> > pero no un desarrollo a fondo ni un trabajo coordinado. Una vez creado,
> > nos podemos poner en contacto con el compañero que supervisa páginas en
> > español en la wiki, @Dcapillae, se le informa de lo que estamos haciendo
> > y, de paso, seguro que nos hecha un ojo a lo que creemos.
> > *Paralelamente, propongo como punto a votar en próxima reunión de OSM-es
> > crear una sala en Riot (o donde sea) para mantenernos en contacto dicho
> > grupo, sin saturar otros medios*.
> >
> > - En segundo lugar, hay que hacer algo respecto a Verdy_p. Este señor va
> > a ser un estorbo grande, y sólo va a conseguir desanimar a cualquiera
> > que quiera participar en el desarrollo de la wiki. _Esto último es lo
> > que más me preocupa_: yo ya estoy viejo como para ofenderme por
> > chorradas o para no seguir adelante con mi trabajo por culpa de un
> > individuo. *Propongo como punto a votar en próxima reunión que OSM-es
> > presente una queja formal a la OSMF sobre este asunto*.
> >
> >
> > Como siempre, siento el tocho ;-) . Un cordial saludo,
> >
> > Diego
> >
> >
> > ___
> > Talk-es mailing list
> > Talk-es@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-es
> >
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[Talk-es] Reflexiones y propuestas para la OSM-es tras mi paso por la wiki

[Diego García]

Hola a todos.

A partir de la propuesta de revisión de calles y de las páginas que creó el
compañero @yopaseopor, he estado estudiando la parte correspondiente a
Aragón. Planteé (en lista aparte) dividir nuestros municipios en comarcas,
del mismo modo que otras comunidades dividieron en provincias, que es una
estructura administrativa muy desarrollada en Aragón. Se aceptó el tema, y
me puse manos a la obra. El resultado de ello ha sido que he creado una
serie de páginas en la wiki (una por comarca), y aparte otra, llamada
Wikiproyecto
Aragón ,
que cuelga del Wikiproyecto España, para centralizar tareas propias de
nuestra comunidad. En conclusión, que he estado bastante activo por la wiki
durante unos días.

No tengo experiencia con la wiki, de hecho se me atraganta un poco, y me ha
tocado estudiar bastante, por lo menos para defenderme. De ahí se desprende
que algún error he ido cometiendo, sobre todo en lo que a recomendaciones
de la wiki se refiere. En cuestión de minutos (cuando creeis páginas lo
comprobareis), la policía me ha dado el alto. Dos son los colaboradores con
los que me he encontrado: uno de ellos me ha informado por *talk *del error
cometido, me ha orientado, me ha puesto referencias, y, como era de
esperar, tenía razón. Le he hecho caso, he cambiado lo que estaba mal, y le
he dado las gracias de todo corazón. Por cierto, es español y se dedica a
supervisar y limpiar páginas en español, según criterios de la wiki. Si me
estás leyendo, un cordial saludo.

Con el segundo la experiencia ha sido diferente. No hablo de que creas una
página y de repente te cambia la pertenencia a no se qué categoría, o el
prefijo, o temas menores. Hablo de que, directamente, cambia el contenido
de la página sin debate previo. Le deshago el cambio argumentando, y él
deshace de nuevo mi cambio, diciendo que "This is the community... ". Sigue
la broma, y no sólo deja todo como yo lo puse (con lo que me da la razón y
demuestra que lo suyo era una rabieta), sino que se repasa unas cuantas
páginas más y, como tampoco ve por dónde tocar (soy "fino" creando
contenido), allí donde ve la posibilidad hace cambios de pertenencia a
categorías.
https://wiki.openstreetmap.org/w/index.php?title=ES:Wikiproyecto_España/Aragón=history
Por cierto, NO es español, y se dedica a supervisar y tocar páginas en
cualquier idioma, según *sus* propios criterios por lo que he podido
comprobar. Nótese la diferencia.

Efectivamente, ya lo hemos conocido antes. Se trata de Verdy_p, y espero
que esté atento a la lista española. Ha tenido lios de la misma índole con
varios paises, y empiezo a pensar que quizá sea un motivo de peso para que
la wiki no esté más desarrollada y ordenada.
https://wiki.openstreetmap.org/wiki/User_talk:Verdy_p

Con toda la experiencia de estos días, propongo dos puntos para la próxima
reunión de la asociación:

- En primer lugar, *afianzar un grupo dedicado a poner orden en la parte
española de la wiki, con una cabeza pensante que coordine esfuerzos* (ó
dinamizador, que es como se dice en las reuniones de la OSM-es  ;-)  ).
Esto ya se decidió en la primera reunión de la asociación,
https://wiki.openstreetmap.org/wiki/ES:Acta_20160906 , pero no quedó muy
claro el asunto, y no se especificó un grupo para la wiki, y pienso que es
importante sentar la bases de un grupo propio desde YA. He visto pinceladas
importantes, (organización del Wikiproyecto España, p.ej.), pero no un
desarrollo a fondo ni un trabajo coordinado. Una vez creado, nos podemos
poner en contacto con el compañero que supervisa páginas en español en la
wiki, @Dcapillae, se le informa de lo que estamos haciendo y, de paso,
seguro que nos hecha un ojo a lo que creemos. *Paralelamente, propongo como
punto a votar en próxima reunión de OSM-es crear una sala en Riot (o donde
sea) para mantenernos en contacto dicho grupo, sin saturar otros medios*.

- En segundo lugar, hay que hacer algo respecto a Verdy_p. Este señor va a
ser un estorbo grande, y sólo va a conseguir desanimar a cualquiera que
quiera participar en el desarrollo de la wiki. *Esto último es lo que más
me preocupa*: yo ya estoy viejo como para ofenderme por chorradas o para no
seguir adelante con mi trabajo por culpa de un individuo. *Propongo como
punto a votar en próxima reunión que OSM-es presente una queja formal a la
OSMF sobre este asunto*.


Como siempre, siento el tocho ;-) . Un cordial saludo,

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

Re: [Talk-es] Limpieza de etiquetas innecesarias o mal usadas.

[Diego García]

Buenas tardes de nuevo.

Siendo así, perfecto. Es muy buena idea lo de sólo tocar los que estén en
versión 1. Pero ya verás qué cantidad de polígonos comparten nodos con
otros elementos que no tienen nada que ver; es mucha gente editando sin
ningún cuidado desde que se metió el corine.

¿Te has planteado lo del osmose? Podría ser una solución para lo de los
vértices y problemas de etiquetado.

Un saludo,



El vie., 6 ene. 2017 a las 18:55, Matías h (<taborda.barr...@gmail.com>)
escribió:

> Hola.
>
> Lo de CORINE es difícil de gestionar,  pero hay que reconocer que la
> mayoría de los polígonos no se corresponde con la realidad.
>
> Lo que  propuse es como mucho borrar aquellos polígonos que aún estén en
> su versión 1 y que por lo  tanto no deberían compartir ni un solo nodo con
> ninguna otra entidad. Por descontado,  que en cuanto algún polígono haya
> sido tocado en alguna edición,  ya no se puede borrar...
>
>
> El 6 ene. 2017 18:30, "Diego García" <dgerv...@gmail.com> escribió:
>
> Buenas tardes a todos.
>
> Aparte de decir que me parece un gran acierto esta limpieza, querría
> mencionar dos detalles:
>
> - Lo último que habría que hacer con CORINE sería eliminar los polígonos
> existentes. No sólo dejaría un hueco impresionante en todo el mapa: el
> problema principal es que muchos nodos están compartidos (por vicios de
> edición) con elementos como carreteras, caminos, ... y lo que pille.
> Eliminar un trozo de bosque de CORINE suele implicar destrozar un tramo de
> vía, imaginad si se eliminan de golpe todos los CORINE... destrozo
> asegurado.
>
> - Se podría arreglar la mayoría de etiquetas con la herramienta osmose (
> http://osmose.openstreetmap.fr/es/map/ ), incluído mayúsculas, alturas de
> los vértices, etiquetas obsoletas... O eso, o ya estamos hablado de
> importaciones a lo bruto, como con el caso de los vértices. Con osmose, por
> ejemplo, las elevaciones con formato incorrecto se pueden ver desmarcando
> todas las casillas de la izquierda, y dejando marcada "mal etiquetado -
> valor numérico". Además, permite corregirlas en línea, desde la misma
> página.
>
>
> Un saludo,
>
> El jue., 5 ene. 2017 a las 13:57, Jorge Sanz Sanfructuoso (<
> sanc...@gmail.com>) escribió:
>
> Si hay mas que estén así claramente si, a corregirlos todos.
>
> El jue., 5 ene. 2017 a las 13:55, Matías h (<taborda.barr...@gmail.com>)
> escribió:
>
> Hola. Yo es que en la columna que he puesto de ejemplos, no he añadido
> todas las etiquetas que considero erroneas en cada grupo de datos, como
> digo sólo en REGENTE hay más de una docena de ellas.
>
> Pero si es verdad que ese valor de ele no es válido. Ya puestos se podrían
> corregir todos los valores de ele que aparezacan así no?.
>
> Gracias.
>
> El 5 de enero de 2017, 13:47, Jorge Sanz Sanfructuoso <sanc...@gmail.com>
> escribió:
>
> He añadido otro error de los Vértices ROI con la key ele.
> A ver si hago memoria que me suena que había mas cosas.
>
> Un saludo
>
> El jue., 5 ene. 2017 a las 12:30, Matías h (<taborda.barr...@gmail.com>)
> escribió:
>
> Hola, buen día.
>
> A raíz de la reunión de la otra noche, se estableció que intentaríamos
> hacer en principio un estudio de los tags que se han usado a lo largo de
> los años (sobre todo en importaciones) que aportan una información
> innecesaria, así como el uso de algunas etiquetas de forma erronea.
>
> He creado en la wiki una tabla para que vayamos aportando algunas ideas y
> casos que nos vayamos encontrando y luego ya decidiremos la forma de
> actuar. [1]
>
> Por otro lado, aunque el pasado martes se mencionó de pasada, u siguiendo
> con el tema de limpieza, no estaría de más que nos plantearamos hacer
> "algo" con las manchas verdes, CORINE. No me refiero a eliminar a saco, ya
> que muchas modificaciones sobre estas entidades ahora si que se ajustan a
> la realidad, pero en zonas menos mapeadas, siguen estando en su versión
> original.
>
> Aunque lo ideal sería abrir otro hilo para comentar este tema ¿no?
>
> Saludos.
>
> [1] https://wiki.openstreetmap.org/wiki/ES:Limpieza_de_etiquetas
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
> --
> Jorge Sanz Sanfructuoso - Sanchi
> Blog http://blog.jorgesanzs.com/
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listi

Re: [Talk-es] Limpieza de etiquetas innecesarias o mal usadas.

[Diego García]

Buenas tardes a todos.

Aparte de decir que me parece un gran acierto esta limpieza, querría
mencionar dos detalles:

- Lo último que habría que hacer con CORINE sería eliminar los polígonos
existentes. No sólo dejaría un hueco impresionante en todo el mapa: el
problema principal es que muchos nodos están compartidos (por vicios de
edición) con elementos como carreteras, caminos, ... y lo que pille.
Eliminar un trozo de bosque de CORINE suele implicar destrozar un tramo de
vía, imaginad si se eliminan de golpe todos los CORINE... destrozo
asegurado.

- Se podría arreglar la mayoría de etiquetas con la herramienta osmose (
http://osmose.openstreetmap.fr/es/map/ ), incluído mayúsculas, alturas de
los vértices, etiquetas obsoletas... O eso, o ya estamos hablado de
importaciones a lo bruto, como con el caso de los vértices. Con osmose, por
ejemplo, las elevaciones con formato incorrecto se pueden ver desmarcando
todas las casillas de la izquierda, y dejando marcada "mal etiquetado -
valor numérico". Además, permite corregirlas en línea, desde la misma
página.


Un saludo,

El jue., 5 ene. 2017 a las 13:57, Jorge Sanz Sanfructuoso (<
sanc...@gmail.com>) escribió:

> Si hay mas que estén así claramente si, a corregirlos todos.
>
> El jue., 5 ene. 2017 a las 13:55, Matías h ()
> escribió:
>
> Hola. Yo es que en la columna que he puesto de ejemplos, no he añadido
> todas las etiquetas que considero erroneas en cada grupo de datos, como
> digo sólo en REGENTE hay más de una docena de ellas.
>
> Pero si es verdad que ese valor de ele no es válido. Ya puestos se podrían
> corregir todos los valores de ele que aparezacan así no?.
>
> Gracias.
>
> El 5 de enero de 2017, 13:47, Jorge Sanz Sanfructuoso 
> escribió:
>
> He añadido otro error de los Vértices ROI con la key ele.
> A ver si hago memoria que me suena que había mas cosas.
>
> Un saludo
>
> El jue., 5 ene. 2017 a las 12:30, Matías h ()
> escribió:
>
> Hola, buen día.
>
> A raíz de la reunión de la otra noche, se estableció que intentaríamos
> hacer en principio un estudio de los tags que se han usado a lo largo de
> los años (sobre todo en importaciones) que aportan una información
> innecesaria, así como el uso de algunas etiquetas de forma erronea.
>
> He creado en la wiki una tabla para que vayamos aportando algunas ideas y
> casos que nos vayamos encontrando y luego ya decidiremos la forma de
> actuar. [1]
>
> Por otro lado, aunque el pasado martes se mencionó de pasada, u siguiendo
> con el tema de limpieza, no estaría de más que nos plantearamos hacer
> "algo" con las manchas verdes, CORINE. No me refiero a eliminar a saco, ya
> que muchas modificaciones sobre estas entidades ahora si que se ajustan a
> la realidad, pero en zonas menos mapeadas, siguen estando en su versión
> original.
>
> Aunque lo ideal sería abrir otro hilo para comentar este tema ¿no?
>
> Saludos.
>
> [1] https://wiki.openstreetmap.org/wiki/ES:Limpieza_de_etiquetas
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
> --
> Jorge Sanz Sanfructuoso - Sanchi
> Blog http://blog.jorgesanzs.com/
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
> --
> Jorge Sanz Sanfructuoso - Sanchi
> Blog http://blog.jorgesanzs.com/
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Posiblidad de hacer una super-macro actualización de datos en la zona España

[Diego García]

Hola Juanma, un saludo.

Lo que planteas no es viable, si te he entendido bien. Quieres traer datos
de topohispania a OSM, y eso es totalmente imposible.

Vengo de (probablemente) el mismo mundo que tú: GPS Garmin o twonav,
bicicleta, senderismo, montaña, y harto de mapas que dejan mucho que
desear. Voy con la bici y, a veces, hasta coincide la vía representada en
el GPS por el sitio donde voy. Meto el topohispania en mi GPS y, sorpresa,
me aparecen muchas más cosas, pero siguen sin coincidir. Algo raro ocurre y
no tardo en darme cuenta: topohispania es una importación del IGN, aunque
mejor hecha y más completa que los oficiales de Garmin o twonav.

Descubro el IGN y el pnoa, y veo el cielo abierto: decido hacer mis propios
mapas, de mi zona, para mí y nadie más. Bebo de varias fuentes y consigo un
mapa hecho por mí que me da mil vueltas a cualquiera. Pero sólo lo puedo
usar yo, y me gustaría que fuera para todo el mundo. Entonces descubro OSM,
y tengo la misma idea que tú.

Es el mapa ideal. Lo hago yo, para mí o para cualquiera que lo necesite.
Pero OJO, no puedo hacer lo que quiera, y se entiende cuando estudias lo
que pone en la wiki, y lo que hacen los demás. Aquí no puedes sacar datos
de cualquier sitio. Las fuentes tienen que ser expresamente libres, o
mejor, debes obtenerlas por tí mismo, a veces con el GPS en la mano. Eso lo
tuve claro desde el principio, y me limitó a trabajar en una única zona,
por la que me muevo, con datos de primera mano obtenidos por mí, apoyado
por las ortofotos del pnoa. He ido a más y, actualmente, te puedo asegurar
que la zona que trabajo le da trece mil vueltas al Garmin, al twonav, al
IGN y al topohispania todos juntos.

Y me temo que topohispania no es libre. Se formó a partir de los datos del
IGN, por lo que su importación a OSM no es viable: sería como hacer una
importación masiva desde IGN, lo que tiene unas reglas muy estrictas ya
establecidas, entre ellas que los datos deben tomarse de la fuente
original, es decir, del propio IGN (sea pnoa, btn, o lo que sea). Si se
traen datos de topohispania eso no se cumple ni de lejos.

Insisto: si te he entendido bien, quieres traer datos de topohispania a
OSM. NO se puede, los datos de topohispania vienen del IGN. Has comparado
zonas poco mapeadas en OSM con topohispania y te has llevado la (falsa)
sensación de que en OSM faltan cosas que sí están en topohispania. Créeme,
ese error ya lo hemos cometido muchos, no eres el primero.

Te animo a que hagas lo que yo: mapea tu zona en OSM, en los términos que
se permite. Te divertirás y tus datos servirán para que la gente que te
visite tenga un mapa de verdad, varios niveles por encima del topohispania.
Y, recíprocamente, cuando visites mi zona, obtendrás lo mismo. Que mi
trabajo le sirva a otros es una de las cosas que más me llenan hoy en mi
vida, con diferencia.

Un cordial saludo,




El vie., 23 dic. 2016 20:14, juanmaf...@gmail.com 
escribió:

Hola, Santiago.

Los datos ya los tengo, sin metadatos, salvo el nombre y el tipo
(etiquetado garmin) falta agregar las correspondientes etiquetas OSM, pues
el topoHispania, como he dicho, usa el etiquetado de garmin.

Mi idea actual es, partiendo de los datos de OSM , añadir un montón de
nuevos datos que no están en OSM,  entre ellos las charcas y lagunas, y
crear un mapa en formato mapsforge,(con la idea de poder usarlo en
Oruxmaps, que es lo que me llevo  al campo), por eso he ofrecido los datos
nuevos.

Por supuesto que cuando OSM actualice nuevos datos los iré cogiendo y
añadiendo al proyecto.

Muchas gracias, Santi, miraré a ver si cuando acabe con el mapa puedo
colaborar con vosotros, que seguro que sí.

Un saludo.

El 23/12/2016 19:48, "Santiago Crespo"  escribió:
>
> Hola juanmafont, bienvenido!
>
> ¿Por qué no coger los datos de las fuentes originales?
>
> Por ejemplo, para las lagunas ya hemos empezado a preparar una posible
> importación del IGN:
> https://wiki.openstreetmap.org/wiki/ES:Import_BTN25_Lagoons
>
> Aquí tienes unas lagunas de ejemplo, generadas con los procedimientos y
> scripts que pone en la wiki:
> http://flanera.net/LAGUNAS-Guipuzkoa.osm
>
> Y aquí las lagunas de España, que podrían valerte para tu mapa (ojo, son
> 290MB al descomprimirlo y hay que dar reconocimiento al IGN)
> http://flanera.net/LAGUNAS-España.osm.7z
>
> Unos pantallazos del JOSM mostrando el archivo anterior:
> http://i.imgur.com/Aqhz2i0.png
> http://i.imgur.com/MBB2eI2.png
>
> Además de la forma de la laguna, hay metadatos interesantes: si es
> permanente o no, agua dulce o salada, etc.
>
> El IGN está hablando con la OpenStreetMap Foundation. Si todo va bien,
> tendremos una carta de autorización expresa para a usar todos sus
> productos digitales para mejorar OSM.
>
> Si te sigue interesando la idea de mejorar OSM importando datos, hay que
> seguir las "Import Guidelines" y el "Automated Edits code of conduct":
>
> http://wiki.osm.org/wiki/Import/Guidelines
>
> 

Re: [Talk-es] Buenas práctica al mapear, en la wiki

[Diego García]

Actualizado con sección uso correcto de la etiqueta name

Un saludo,

El dom., 16 oct. 2016 a las 17:44, Iñaki ()
escribió:

> Buenas tardes:
>
> Buen comentario, sobre todo eso de hacer la "vida más fácil a todos".
> Gracias.
>
> Iñaki
>
> El 16/10/2016 a las 0:16, yo paseopor escribió:
>
> Buenas gente
>
> Os escribo un correo breve para explicaros que a raíz de unos comentarios
> en el grupo de Telegram me he decidido a crear una página en la wiki que
> explique casos concretos y muy sencillos de cómo se deben hacer las cosas
> (y así evitar trabajos superfluos).
> La página es
> https://wiki.openstreetmap.org/wiki/WikiProject_Spain/Buenas_pr%C3%A1cticas y
> os animo a todos y todas a que expongais vuestros casos, a ser posible con
> imagen y todo. Recordad que no es un lugar para pontificar sino para
> hacernos la vida más fácil a todos un poco, ya sabeis, con educación todo
> es debatible, hasta la existencia humana ;)
>
> Vivimos en Matrix? ;)
>
> Salut i bones pràctiques
> yopaseopor
>
>
> ___
> Talk-es mailing 
> listTalk-es@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-es
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] mapear caminos, senderos. vías pecuarias, senderos homologados..

[Diego García]

Por experiencia, para el tema de sendas y caminos, mejor que por
cuadrantes, por términos municipales. Ahora escribo desde el móvil, y es
complicado extenderse, pero luego desde casa, si quieres, te lo argumento.

Un saludo

El mar., 18 oct. 2016 15:06, Francisco Javier 
escribió:

> Te explico. lo que pretendo hacer es ir por cuadratantes para hacer todos
> los caminos y senderos pero sin añadir ninguna ruta, solamente lo que es el
> trazado y al estar encuadrado es más fácil darle un repaso por si me dejo
> algún camino sin dibujar o veo que algún trazado está mal dibujado. Una vez
> que la provincia/comunidad autónoma tiene todos los caminos hechosy
> senderos, sería mirar el wiki y completarlo con las rutas de los senderos
> homologados o las rutas de los ayuntamientos (ya no haría falta el gestor
> de tareas y con iD/JOSM es más que suficiente.
>
> Si me das permisos en el gestor de tareas genial así pruebo como funciona
> porque estuve el otro día cotilleando en el taks humanitario y me pareció
> una idea muy buena.
>
> Te dejo mi página usuario por si necesitas darme los permisos:
> http://tareas.openstreetmap.es/user/JavierSp
>
> Un saludo.
>
> El 18 de octubre de 2016, 14:07, Alejandro S. 
> escribió:
>
> Hola,
>
> Si te he entendido bien, creo que en este caso, es preferible organizarse
> a través de la wiki, añadir allí el listado completo de senderos de una
> provincia e ir introduciendo los caminos uno tras otro. Creo que no será
> cómodo ir por cuadrantes, ya que es más difícil "seguir" una ruta.
>
> De todas formas, si quieres, te doy permisos en el Gestor de Tareas y
> haces una tarea de prueba sin publicar.
>
> En cuanto a completar la wiki, adelante, es lo que deberíamos hacer todos.
>
> Saludos ,
>
> Alejandro Suárez
>
> On Mon, Oct 17, 2016, 23:40 Francisco Javier  wrote:
>
> Buenas a todos.
>
> Peguntando en Telegram sobre mapear provincias de la forma como la hacen
> en http://tasks.hotosm.org/ me han pasado un enlace que tenéis para estos
> casos: http://tareas.openstreetmap.es/
>
> El caso es que llevo haciendo caminos y senderos de Castilla y león desde
> hace un año, mas concretamente la parte de León y he pensado que podríamos
> hacer tareas de cada provincia ya que sería mucho más cómodo al dividirse
> el trabajo en "cuadraditos" (tareas).
>
> Si mal no recuerdo un compi ha comentado que burgos está casi terminado y
> sólo falta un 25% de caminos y senderos por hacer, así que podríamos
> empezar por ahí. León también está bastante completo así que podríamos
> tirar por ahí hasta finiquitar toda el resto de provincias que componen
> Castilla la Mancha para más adelante seguir con otras comunidades autónomas.
>
> Una vez que tengamos hecho los caminos, senderos etc.. podríamos agregar
> las rutas homologadas que falten, rutas verdes, vías pecuarias y demás
> elementos.
>
>
> Otra cosa que quería comentar es que he estado viendo en el Wiki, los
> senderos y se podría (yo podría hacerlo) ordenar todo un poco mejor
> haciendo subpaginas y enlazando todo desde la principal porque ahora mismo
> esta todo mezclado, rutas homologadas y rutas de cada ayuntamiento..
>
> Ejemplo:
> Senderos > Rutas internacionales / E - European
> Senderos > Rutas nacionales / GR - Gran Recorrido
> Senderos > Rutas Regionales / PR - Pequeño Recorrido
> Senderos > Otro tipo de rutas no homologadas pero que si son oficiales por
> los ayuntamientos o comunidades autónomas
>
> Me dejo alguna alguna cosa más como las vías pecuarias (más de 1500 que
> hay por cada comunidad autónoma y muchas desaparecidas) Pero esto da para
> otro tema..
>
> *(tranquilo yopasepor, no pondré mis rutas favoritas con nombre hiperchulo
> :(
>
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Comarcalización de España

[Diego García]

Mi intención no era abrir este debate, sino aportar la manera de crear
dichos límites.

Un saludo,

El jue., 6 oct. 2016 a las 10:34, Emilio Gómez Fernández (<
emilio.gomez.f...@gmail.com>) escribió:

> Yo estoy de acuerdo con lo que dice Pepe y David. Es absurdo definir unas
> comarcas en CA.AA. donde no existen o no se han desarrollado las leyes de
> comarcalización. En Cantabria, por ejemplo, existe la ley de 1999, pero
> estas no se han creado y pasará tiempo si se llegan a formar. Sí existe una
> comarcalización sanitaria, educativa, ganadera, etc. ninguna de las cuales
> coincide plenamente con las otras y ninguna va más allá de los ámbitos a
> las que están supeditadas.
>
> A veces vemos mapas o tratamos de forzar unas comarcas actuales basándonos
> en los límites de comarcas históricas que ya no existen y no tiene ningún
> valor administrativo. A parte de que muchas veces estas entran en conflicto
> unas con otras: la comarca histórica de los valles pasiegos, la
> pasieguería, rebasa los límites de la actual Cantabria hacia la comarca
> burgalesa de Las Merindades, por ejemplo.
>
> En conclusión, mi postura es fijar las comarcas ajustándonos a la premisa
> de verificabilidad de OSM: si están definidas legal y administrativamente
> se incorporan, sino no.
>
> Un saludo.
>
> Emilio Gómez
>
>
>
> El 6 de octubre de 2016, 8:44, David Marín Carreño <dav...@gmail.com>
> escribió:
>
> Entiendo que esta comarcalización sólo habría que hacerla en aquellas
> comarcas administrativamente definidas, lo que sucede en algunas
> comunidades autónomas (según la Wikipedia: Aragón, Asturias, Galicia,
> Cataluña y el Bierzo en Castilla-León), pero no en el resto...
>
> Por ejemplo, ¿qué hacer con Andalucía? Porque tirando de otro artículo de
> wikipedia, veo que Andalucía tiene un listado de comarcas oficial a
> efectos de planificación de oferta turística y deportiva:
> http://web.archive.org/web/20081230071759/http://www.derechodeportivo.org/legislacion/orden%20comarcas.pdf
>  . Sin embargo en el estatuto andaluz de autonomía de 2007 aparece la
> figura de comarca como ente entre la provincia y el municipio, pero aún no
> se ha creado ninguna...
>
>
>
>
> El mié., 5 oct. 2016 a las 22:38, Pepe Casado (<pcvalve...@gmail.com>)
> escribió:
>
> Buenas, quiero plantear una cuestión al respecto de las comarcas. Ahora
> mismo dependiendo de la comunidad autónoma las comarcas pueden ser
> unicamente un ente histórico, una realidad sentimental, me explico; por
> ejemplo en Castilla y Leon administrativamente no tiene ninguna función,
> salvo El Bierzo, en León, que es la única comarca funcionalmente existente
> en toda la comunidad autónoma, por cierto la más grande de Europa.
>
> Hacer o significar algo que realmente no existe como tal no lo acabo de
> ver, aunque muchos quisiéramos que así fuera. Si el mapa tiene que
> representar una realidad administrativa como tal no veo que deba delimitar
> algo que no existe, insisto ya me gustaría.
>
> Administrativamente y orgánicamente muchos de los territorios ahora se
> organizan como mancomunidades, organo supramunicipal que funciona por la
> unión de varios municipios para dar determinados servicios que de manera
> individual se hace inviable económicamente, cómo la recogida de basuras.
>
> Siento ser negativo quizás pero esa es la realidad en muchos lugares de
> España. Otra cosa y que aplaudo, es que OSM represente una realidad
> histórica y un sentimiento que muchos quisiéramos fuese real.
>
> Siento la chapa pero al título del correo solo puedo decir esto.
>
> SaludOSM
>
> Pepe Casado
> Villarcayo
> Las Merindades
> Burgos
>
> El 5 oct. 2016 22:12, "Jorge Sanz Sanfructuoso" <sanc...@gmail.com>
> escribió:
>
> Yo también me sorprendido al verlo que estaba dividido, no se si pasara en
> algún sitio mas.
>
> El mié., 5 oct. 2016 a las 22:08, Diego García (<dgerv...@gmail.com>)
> escribió:
>
> Es otro buen truco para hacerlo, más sencillo que el que he puesto. Yo lo
> uso cuando tengo que bajarme municipios de una provincia adjacente.
>
> Respecto a lo segundo, es complicado. No pensaba que hubiera excepciones,
> y que un municipio se partiera entre dos comarcas. Igual sería cuestión de
> dibujar la frontera que lo divide y crear dos relaciones de frontera
> political, para añadir cada una de ellas a la comarca que corresponda. Si
> no se hace bien lo de las subáreas, al preguntar desde OSM las
> características de un punto, no sale la comarca que corresponde en las
> envolventes.
>
>
> Un saludo,
>
> El mié., 5 oct. 2016 a las 22:01, Jorge Sanz Sanfructuoso (<
> sanc...@gmail.com>) escribió:
>
> Hola.
>
> Yo en ve

Re: [Talk-es] Comarcalización de España

[Diego García]

Es otro buen truco para hacerlo, más sencillo que el que he puesto. Yo lo
uso cuando tengo que bajarme municipios de una provincia adjacente.

Respecto a lo segundo, es complicado. No pensaba que hubiera excepciones, y
que un municipio se partiera entre dos comarcas. Igual sería cuestión de
dibujar la frontera que lo divide y crear dos relaciones de frontera
political, para añadir cada una de ellas a la comarca que corresponda. Si
no se hace bien lo de las subáreas, al preguntar desde OSM las
características de un punto, no sale la comarca que corresponde en las
envolventes.


Un saludo,

El mié., 5 oct. 2016 a las 22:01, Jorge Sanz Sanfructuoso (<
sanc...@gmail.com>) escribió:

> Hola.
>
> Yo en vez de andar atinando el punto de la capital lo que hago es irme a
> la frontera de la provincia a cualquier lugar que sea campo y a poco que te
> acerques ya tienes solo la linea de la provincia sin nada que se entrometa.
>
> En cuanto al subarea tengo una duda. Tengo un par de comarcas que dividen
> un municipio en 2. ¿Pongo el municipio a las 2 comarcas?
>
> Un saludo
>
>
>
> El mié., 5 oct. 2016 a las 21:44, Diego García (<dgerv...@gmail.com>)
> escribió:
>
> Tienes razón. En todas la que he creado lo he puesto, incluso el website
> de cada una.
>
> Un saludo,
>
> El mié., 5 oct. 2016 21:40, Óscar Zorrilla Alonso <
> oscar_zorri...@hotmail.com> escribió:
>
> Hola Diego;
>
>
> Tan sólo una sugerencia, añadir wikipedia a la relación:
>
> wikipedia - es:la_comarca_que_sea
>
> Un saludo
> --
> *De:* Diego García <dgerv...@gmail.com>
> *Enviado:* miércoles, 5 de octubre de 2016 21:21
> *Para:* Discusión en Español de OpenStreetMap
> *Asunto:* [Talk-es] Comarcalización de España
>
> Buenas tardes a todos.
>
> A raíz de conversaciones surgidas en el canal de Telegram, voy a exponer a
> continuación una serie de pautas y ayudas, al estilo de un "how to", para
> crear las relaciones que definen una comarca. Mi intención es que se
> revise, critique y consensúe el texto para su posterior conversión en
> página de la wiki. O lo dejamos en esta lista, que también se puede
> consultar y no lo vamos a necesitar más adelante cuando estén creadas las
> comarcas. Editores más avanzados encontrarán este texto poco útil, mientras
> que algunos noveles en la materia se les puede hacer un poco cuesta arriba.
> Si se hacen capturas de pantalla, puede que mejore el tema. Por favor,
> tomadlo como un tosco borrador:
>
>
>
>
>
>
> *[Aquí iría una pequeña introducción de lo que son las comarcas, utilidad
> de su representación en OSM, etc. Queda bien y sitúa al lector. El primer
> párrafo de la wikipedia es bastante conciso para ello
> https://es.wikipedia.org/wiki/Comarcas_de_Espa%C3%B1a
> <https://es.wikipedia.org/wiki/Comarcas_de_Espa%C3%B1a> ] *
>
> * Comarcas de España - Wikipedia, la enciclopedia libre
> <https://es.wikipedia.org/wiki/Comarcas_de_Espa%C3%B1a> es.wikipedia.org
> <http://es.wikipedia.org> El vasto espacio, escasamente compartimentado, de
> la Meseta del Duero, junto a los factores históricos que determinaron una
> característica división provincial en ... *
>
> Las comarcas se definen en OSM como una relación de tipo boundary
> (frontera) con nivel administrativo 7. Agrupan siempre a una serie de
> municipios, que pueden pertenecer a distintas provincias, por lo que no
> serán relaciones hijas de una relación admin_level 6 (provincia), sino de
> la comunidad autónoma a la que pertenecen (admin_level 4)
>
> En primer lugar, debemos tener claro cuáles son sus límites, qué
> municipios la componen y cuál es su capital. Esta información la podemos
> obtener de wikipedia. Por ejemplo, consultando la página correspondiente a
> Tarazona y el Moncayo, veremos que la capital es Tarazona, que la componen
> 16 municipios, y que a la derecha tenemos un pequeño mapa que nos ayudará a
> seguir el límite cuando lo definamos en OSM.
>
> A partir de aquí, teniendo claro lo que vamos a hacer, hay que ver qué
> necesitamos. Como vamos a trabajar con relaciones, lo apropiado es utilizar
> JOSM, por lo que lo ejecutaremos. Una vez en marcha, bajaremos los datos
> que necesitamos. En este caso nos hace falta tener los municipios, y pueden
> encontrarse fácilmente bajando las relaciones hijas de la provincia a la
> que pertenecen. La forma más fácil es buscar el nodo que contiene la
> capital de dicha provincia y bajarnos sólo ese nodo (usuarios más avezados
> pueden tirar de overpass, etc) para no tener demasiados elementos en el
> mapa que nos podrían estorbar. Truco para los que tengan menos práctica:
> localizamos el nombre del nodo y nos vamos acercando; antes de que
> desa

Re: [Talk-es] Comarcalización de España

[Diego García]

Tienes razón. En todas la que he creado lo he puesto, incluso el website de
cada una.

Un saludo,

El mié., 5 oct. 2016 21:40, Óscar Zorrilla Alonso <
oscar_zorri...@hotmail.com> escribió:

Hola Diego;


Tan sólo una sugerencia, añadir wikipedia a la relación:

wikipedia - es:la_comarca_que_sea

Un saludo
--
*De:* Diego García <dgerv...@gmail.com>
*Enviado:* miércoles, 5 de octubre de 2016 21:21
*Para:* Discusión en Español de OpenStreetMap
*Asunto:* [Talk-es] Comarcalización de España

Buenas tardes a todos.

A raíz de conversaciones surgidas en el canal de Telegram, voy a exponer a
continuación una serie de pautas y ayudas, al estilo de un "how to", para
crear las relaciones que definen una comarca. Mi intención es que se
revise, critique y consensúe el texto para su posterior conversión en
página de la wiki. O lo dejamos en esta lista, que también se puede
consultar y no lo vamos a necesitar más adelante cuando estén creadas las
comarcas. Editores más avanzados encontrarán este texto poco útil, mientras
que algunos noveles en la materia se les puede hacer un poco cuesta arriba.
Si se hacen capturas de pantalla, puede que mejore el tema. Por favor,
tomadlo como un tosco borrador:






*[Aquí iría una pequeña introducción de lo que son las comarcas, utilidad
de su representación en OSM, etc. Queda bien y sitúa al lector. El primer
párrafo de la wikipedia es bastante conciso para ello
https://es.wikipedia.org/wiki/Comarcas_de_Espa%C3%B1a
<https://es.wikipedia.org/wiki/Comarcas_de_Espa%C3%B1a> ] *

* Comarcas de España - Wikipedia, la enciclopedia libre
<https://es.wikipedia.org/wiki/Comarcas_de_Espa%C3%B1a> es.wikipedia.org
<http://es.wikipedia.org> El vasto espacio, escasamente compartimentado, de
la Meseta del Duero, junto a los factores históricos que determinaron una
característica división provincial en ... *

Las comarcas se definen en OSM como una relación de tipo boundary
(frontera) con nivel administrativo 7. Agrupan siempre a una serie de
municipios, que pueden pertenecer a distintas provincias, por lo que no
serán relaciones hijas de una relación admin_level 6 (provincia), sino de
la comunidad autónoma a la que pertenecen (admin_level 4)

En primer lugar, debemos tener claro cuáles son sus límites, qué municipios
la componen y cuál es su capital. Esta información la podemos obtener de
wikipedia. Por ejemplo, consultando la página correspondiente a Tarazona y
el Moncayo, veremos que la capital es Tarazona, que la componen 16
municipios, y que a la derecha tenemos un pequeño mapa que nos ayudará a
seguir el límite cuando lo definamos en OSM.

A partir de aquí, teniendo claro lo que vamos a hacer, hay que ver qué
necesitamos. Como vamos a trabajar con relaciones, lo apropiado es utilizar
JOSM, por lo que lo ejecutaremos. Una vez en marcha, bajaremos los datos
que necesitamos. En este caso nos hace falta tener los municipios, y pueden
encontrarse fácilmente bajando las relaciones hijas de la provincia a la
que pertenecen. La forma más fácil es buscar el nodo que contiene la
capital de dicha provincia y bajarnos sólo ese nodo (usuarios más avezados
pueden tirar de overpass, etc) para no tener demasiados elementos en el
mapa que nos podrían estorbar. Truco para los que tengan menos práctica:
localizamos el nombre del nodo y nos vamos acercando; antes de que
desaparezca por culpa del zoom lo recuadramos y bajamos sólo ese recuadro.
En el centro de lo que hemos bajado, veremos el nodo que buscamos. Nos
acercamos lo más posible al nodo, y le damos de nuevo a descargar. Veremos
que el recuadro propuesto para descargar casi no se ve. Marcamos "descargar
como nueva capa" y le damos a descargar. Cuanto la tengamos, descartamos la
capa anterior y nos quedará una capa que contiene sólo el nodo que buscamos.

Cuando lo tengamos, veremos que forma parte de la frontera de nivel 6
correspondiente a su provincia: abrimos la relación para editar y pasamos a
la pestaña "relaciones hijas". Pinchamos en "descargar todas las hijas", y,
si la relación provincia está bien hecha, nos bajará todas las relaciones
de municipios con sus fronteras correspondientes.

Ahora creamos la relación, por ejemplo con el botón que JOSM tiene en la
parte derecha, dentro del marco "relaciones". Le tenemos que incluir
necesariamente las siguientes etiquetas:

admin_level=7
boundary=administrative
name=[el que le corresponda]
type=boundary
is_in:continent=Europe
is_in:country=Spain
is_in:country_code=ES
is_in:region=[la que corresponda]
is_in:region_code=[la que corresponda]
is_in=[autonomía que corresponda], Spain, Europe

Y pasamos a meter las fronteras. Con la relación abierta iremos
seleccionando cada tramo, dejando para el final los enclaves y exclaves, y
los incluiremos en orden dentro de la relación. Hay que poner especial
cuidado con los enclaves y exclaves. Las primeras deberán llevar el rol
inner, y las segundas el rol ou

[Talk-es] Comarcalización de España

[Diego García]

Buenas tardes a todos.

A raíz de conversaciones surgidas en el canal de Telegram, voy a exponer a
continuación una serie de pautas y ayudas, al estilo de un "how to", para
crear las relaciones que definen una comarca. Mi intención es que se
revise, critique y consensúe el texto para su posterior conversión en
página de la wiki. O lo dejamos en esta lista, que también se puede
consultar y no lo vamos a necesitar más adelante cuando estén creadas las
comarcas. Editores más avanzados encontrarán este texto poco útil, mientras
que algunos noveles en la materia se les puede hacer un poco cuesta arriba.
Si se hacen capturas de pantalla, puede que mejore el tema. Por favor,
tomadlo como un tosco borrador:







*[Aquí iría una pequeña introducción de lo que son las comarcas, utilidad
de su representación en OSM, etc. Queda bien y sitúa al lector. El primer
párrafo de la wikipedia es bastante conciso para ello
https://es.wikipedia.org/wiki/Comarcas_de_Espa%C3%B1a
 ]*

Las comarcas se definen en OSM como una relación de tipo boundary
(frontera) con nivel administrativo 7. Agrupan siempre a una serie de
municipios, que pueden pertenecer a distintas provincias, por lo que no
serán relaciones hijas de una relación admin_level 6 (provincia), sino de
la comunidad autónoma a la que pertenecen (admin_level 4)

En primer lugar, debemos tener claro cuáles son sus límites, qué municipios
la componen y cuál es su capital. Esta información la podemos obtener de
wikipedia. Por ejemplo, consultando la página correspondiente a Tarazona y
el Moncayo, veremos que la capital es Tarazona, que la componen 16
municipios, y que a la derecha tenemos un pequeño mapa que nos ayudará a
seguir el límite cuando lo definamos en OSM.

A partir de aquí, teniendo claro lo que vamos a hacer, hay que ver qué
necesitamos. Como vamos a trabajar con relaciones, lo apropiado es utilizar
JOSM, por lo que lo ejecutaremos. Una vez en marcha, bajaremos los datos
que necesitamos. En este caso nos hace falta tener los municipios, y pueden
encontrarse fácilmente bajando las relaciones hijas de la provincia a la
que pertenecen. La forma más fácil es buscar el nodo que contiene la
capital de dicha provincia y bajarnos sólo ese nodo (usuarios más avezados
pueden tirar de overpass, etc) para no tener demasiados elementos en el
mapa que nos podrían estorbar. Truco para los que tengan menos práctica:
localizamos el nombre del nodo y nos vamos acercando; antes de que
desaparezca por culpa del zoom lo recuadramos y bajamos sólo ese recuadro.
En el centro de lo que hemos bajado, veremos el nodo que buscamos. Nos
acercamos lo más posible al nodo, y le damos de nuevo a descargar. Veremos
que el recuadro propuesto para descargar casi no se ve. Marcamos "descargar
como nueva capa" y le damos a descargar. Cuanto la tengamos, descartamos la
capa anterior y nos quedará una capa que contiene sólo el nodo que buscamos.

Cuando lo tengamos, veremos que forma parte de la frontera de nivel 6
correspondiente a su provincia: abrimos la relación para editar y pasamos a
la pestaña "relaciones hijas". Pinchamos en "descargar todas las hijas", y,
si la relación provincia está bien hecha, nos bajará todas las relaciones
de municipios con sus fronteras correspondientes.

Ahora creamos la relación, por ejemplo con el botón que JOSM tiene en la
parte derecha, dentro del marco "relaciones". Le tenemos que incluir
necesariamente las siguientes etiquetas:

admin_level=7
boundary=administrative
name=[el que le corresponda]
type=boundary
is_in:continent=Europe
is_in:country=Spain
is_in:country_code=ES
is_in:region=[la que corresponda]
is_in:region_code=[la que corresponda]
is_in=[autonomía que corresponda], Spain, Europe

Y pasamos a meter las fronteras. Con la relación abierta iremos
seleccionando cada tramo, dejando para el final los enclaves y exclaves, y
los incluiremos en orden dentro de la relación. Hay que poner especial
cuidado con los enclaves y exclaves. Las primeras deberán llevar el rol
inner, y las segundas el rol outer. [
https://wiki.openstreetmap.org/wiki/ES:Relation:boundary] Si pinchamos en
el botón para ordenar la relación, nos aseguramos de no haber dejado el
polígono abierto.

Ahora seleccionamos el nodo que contiene la capital, y lo incluimos en la
relación. A dicho nodo le daremos el rol admin_centre. Aceptamos, y ya
tenemos creada la relación.

Para definir cada municipio como una subárea de la relación y conseguir que
los municipios correspondientes sean relaciones hijas de la relación que
define la comarca, haremos lo siguiente:

Como tenemos descargadas todas las relaciones de los municipios, abriremos
de nuevo la relación de la comarca para editar, y nos fijaremos en la lista
de relaciones que ofrece JOSM a la derecha. Al salir en orden alfabético,
será fácil cotejarla con la que nos da la wikipedia, manteniendo ctrl
pulsado y pinchando sobre las que pertenecen al municipio para que queden
seleccionadas. 

Re: [Talk-es] Normas grupo Telegram

[Diego García]

+1

Un saludo

El lun., 26 sept. 2016 20:35, Óscar Zorrilla Alonso <
oscar_zorri...@hotmail.com> escribió:

> Hola, esos no serían problemas porque son temas relacionados con
> Openstreetmap en el fondo o temas similares
>
> Obtener Outlook para Android 
>
>
>
> On Mon, Sep 26, 2016 at 8:02 PM +0200, "Xavier Barnada" <
> xbarn...@gmail.com> wrote:
>
> Me parecen bien. El único problema que veo es a la hora de determinar que
> es spam y que no.
> Ejemplos:
> - Info de otros proyectos como Wikipedia
> - Aplicaciones libres de gis ( no osm)
>
> Saludos
>
> El dl., 26 set. 2016, 19:19, Jorge Sanz  va escriure:
>
>> +1
>>
>> 2016-09-26 19:11 GMT+02:00 Alejandro S. :
>>
>>> Estoy de acuerdo con las normas.
>>>
>>> On Mon, Sep 26, 2016, 16:51 Óscar Zorrilla Alonso <
>>> oscar_zorri...@hotmail.com> wrote:
>>>
 Hola;


 Para intentar que el grupo de telegram https://telegram.me/OSMes
 funcione mejor, estamos pensando en pone algunas normas de sentido común.


 ¡Este correo es para hablar sólo de las normas de Telegram, no para
 debatir sobre su uso!

 El debate sobre su uso está en el siguiente hilo
 https://lists.openstreetmap.org/pipermail/talk-es/2016-September/014372.html

 Nos gustaría ver que os parece, sugerencias o cambios. El texto
 sugerido es el siguiente:


 Bienvenidos a la comunidad OpenStreetMap España.

 Para poder disfrutar de esta red de usuarios, es imprescindible
 respetar las normas básicas del grupo.

 1- Queda totalmente PROHIBIDO cualquier tipo de falta de RESPETO, esto
 supondrá la expulsión inmediata del grupo.

 2- Queda PROHIBIDO hacer SPAM.

 3- Los DEBATES deben trasladarse a otro medio como la lista de correo,
 riot.im o gitter.

 4- Este grupo es para hablar de OpenStreetMap y temas relacionados. Los
 debates sobre política, fútbol o religión no forman parte de este grupo, ya
 hay otros lugares para debatirlos.

 5- Cualquier duda o incidencia, debe ser comunicada por privado a los
 administradores

 * Desde la administración OpenStreetMap España recomendamos un uso
 responsable de este medio para que sea manejable y cómodo a todos los
 usuarios.

  ESPAÑA
 Lista de correo
 https://lists.openstreetmap.org/listinfo/talk-es

 Twitter
 https://twitter.com/openstreetmapes

 Telegram
 https://telegram.me/OSMes

  Página de la Wiki sobre el mapeado en España.
 http://wiki.openstreetmap.org/wiki/WikiProject_Spain

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

>>>
>>> ___
>>> Talk-es mailing list
>>> Talk-es@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-es
>>>
>>>
>>
>>
>> --
>> Jorge Sanz
>> http://www.osgeo.org
>> http://wiki.osgeo.org/wiki/Jorge_Sanz
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Ermitas

[Diego García]

Totalmente de acuerdo contigo. De hecho, en la ayuda de josm, sale de ese
modo.

Un saludo

El vie., 16 sept. 2016 14:20, Santi Aguirre 
escribió:

> Hola a todos,
>
> He visto que el usuario de nombre “Ermitas de Navarra” hará un año puso
> una gran cantidad de ermitas en Navarra con la etiquetas building=hermitage
> y building=Hermitage.
>
> Eso me ha hecho dudar de si estaba yo etiquetando correctamente las
> ermitas como building=chapel. Un vistazo a la Wikipedia en inglés [1] me ha
> dado a entender que “hermitage” es el lugar donde vivía un ermitaño, y no
> tiene por tanto la misma acepción que en castellano. Según la RAE es "una
> capilla o santuario, generalmente pequeños, situados por lo común en
> despoblado y que no suelen tener culto permanente" cuya traducción creo que
> se aproxima más a “chapel”.
>
> Una consulta en overpass muestra también que en el resto del Mundo
> “hermitage” no se utiliza [2].
>
> ¿Estais de acuerdo con lo expuesto? Mi idea sería mandar un mensaje al
> usuario navarro informándole y hacer el cambio de forma masiva de los
> “hermitages” desperdigados por España añadiendo además la etiqueta
> denomination=roman_catholic.
>
> Un saludo
>
> [1] https://en.wikipedia.org/wiki/Hermitage_(religious_retreat)
>
> [2]: http://overpass-turbo.eu/s/iq6
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Respuesta para las preguntas y dudas sobre propuesta de cambios en la normalización para las vías interurbanas

[Diego García]

Buenas tardes a todos.

Héctor, vaya por delante que considero que estás haciendo un buen trabajo,
en todos los sentidos. Puede parecer que lo digo por decir, pero no es así.
Me quito el sombrero ante tu capacidad de trabajo por todo lo que has
desarrollado en estos días.

Hay un punto en todo este asunto para el que es muy probable que haya
consenso unánime: *las carreteras de nuestro país necesitan un repaso a
fondo en OSM*. Tu propuesta es una posible solución al problema, pero
muchos de nosotros le vemos fallos y planteamientos que no compartimos. Si
para cada pega o alternativa que se encuentra, rebates exponiendo de nuevo
el problema (con ejemplos de carreteras, desvaríos de la administración,
etc), esto no avanza, porque seguiremos estando de acuerdo con que existe
el problema, pero no con la solución. Deberíamos partir de los elementos en
los que estemos de acuerdo, y luego seguir una vez asentados éstos.

Lo primero de todo es dejar claro que *actualmente*, la clave highway
recoge la función que tiene esa vía. En eso debemos estar de acuerdo, es
algo obvio y recogido por la normalización actual. Tu propuesta supondría
el cambio de esa clave, que pasaría a significar características de la vía.
Y yo digo que las características de la vía deberían estar en otras claves
más adecuadas, como ancho de la vía, número de carriles, existencia de
arcén, velocidad máxima permitida, etc. Si haces una tabla con todas esas
características y, para una combinación dada de ellas, le asignas un valor
de highway, estás duplicando información por un lado (las características),
y perdiendo la correspondiente a la función por otro. Y contra eso, todavía
no he visto ningún argumento que lo rebata.

Otra historia es el render (mapnik, entre otros), que nos dibuja las
carreteras según la clave highway, es decir, atendiendo a su función. Eso
hace que tengamos el territorio cruzado de líneas rosas, para carreteras
que resultan no tener arcén, ni carriles, ni señalización horizontal, y
algunas amarillas de verdaderas autopistas. ¿Esto se corresponde a la
realidad de las características de la vía? Por supuesto que no, pero no es
culpa de los datos contenidos en OSM, es culpa del render, que nosotros no
controlamos ni definimos. Y no perdamos de vista que OSM es una base de
datos, no un render. ¿Que los GPS nos mandan por una carretera u otra
atendiendo al highway y a la velocidad máxima? En un mundo ideal deberían
atender a las características de la vía. Si yo programase una aplicación
para GPS, teniendo a mano una base de datos como OSM, no dudaría en hacerlo
de ese modo.

Sobre el tema de clasificar atendiendo a la administración a la que
pertenece una carretera: *estoy de acuerdo contigo*. No debería ser tenido
en cuenta este parámetro, llevado a rajatabla da lugar a sin sentidos, como
los ejemplos que expones y alguno más que me conozco. Clasifiquemos según
función de la vía, a mi entender es lo adecuado.

Muchas trunk perdieron su función hace mucho, deberían dejar de serlo por
este motivo; y algunas autonómicas/comarcales son verdaderas
carreteras/autovías, que unen grandes distancias, o grandes poblaciones. En
mi zona, hay una unclassified de más de treinta kilómetros, que es el único
acceso a varios pueblos que de otro modo estarían aislados, debería ser
tertiary. Pienso que lo que tenemos que hacer es revisar la función de las
carreteras, sin cambiar el significado de la clave highway. Y,
paralelamente, meter a cascoporro datos como ancho de la vía, arcén,
velocidades, etc, etc, etc, para que estén ahí, sean reales, y puedan ser
utilizados por las aplicaciones que se tomen en serio este asunto.

Un cordial saludo,

Diego.




El dom., 8 may. 2016 a las 20:10, yo paseopor ()
escribió:

> Sí, puesto que no se corresponde con la realidad. Se parte de la base que
> las del Estado son "más importantes" por el hecho de ser del Estado, no
> importa que la carretera sea un desastre, no se invierta en ella desde hace
> años.Hay muchos ejemplos en los artículos y y respuestas previas.
>
> 
>
> http://yopaseopor.blogspot.com.es/2016/04/yomapeo-opinion-sobre-el-cambio-de.html
>
> http://yopaseopor.blogspot.com.es/2016/05/yomapeo-opinion-sobre-el-cambio-de.html
>
>
> Y por el contrario se considera que las autonómicas son "menos
> importantes" por el hecho de ser autonómicas, no importa que la carretera
> sea nueva de trinca,supere en criterios objetivos a algunas carreteras
> nacionales, vertebre el territorio, etc. etc.
>
> Para ser una persona que recorro bastante el territorio no me gusta verme
> discriminado (el mapa empieza a fallar) , más si nos dejamos de indicar
> buenas vías sólo por el simple hecho de no pertenecer al Estado. Para eso
> ya  tengo a Google Maps.OSM debe ir más allá. Por ello esta propuesta de
> normalización basada en criterios técnicos, no sólo en la administración de
> la que dependen
>
> https://wiki.openstreetmap.org/wiki/User:Yopaseopor
>
> La situación 

Re: [Talk-es] Propuesta de cambios en la normalización para las vías interurbanas

[Diego García]

Ahondando en lo mismo, y no queriendo ser repetitivo, hay dos puntos que
menciona Alejandro que son claves, por eso me gustaría hacer hincapié:

- En primer lugar, no habría que revisar la normalización, sino cómo
tenemos la vías en el mapa. Ahí sí hay mucha tela que cortar.
- Y en segundo lugar, la propuesta supone dedicir el valor de highway según
qué valores tengan el resto de etiquetas, lo que resulta en la duplicidad
de información.

Un saludo,

Diego

El mié., 4 may. 2016 a las 20:03, Alejandro S. (<alejandro...@gmail.com>)
escribió:

> Buenas a todos,
>
> En primer lugar, menuda currada Hector, pero coincido con Diego, no creo
> que sea necesario revisar la normalización. Con tu propuesta (highway en
> función de características de la vía) lo que se conseguiría es tener
> duplicada esa información de las características (maxspeed, smothness...),
> actualmente ya podemos reflejar esa información y adicionalmente mediante
> el highway el responsable de la vía (¿igual lo deberíamos poner como
> operator también?).
>
> Si quisiéramos cambiar la normalización pienso que sería más interesante
> hacerlo para que la etiqueta highway refleje la función de la vía, Por
> ejemplo preguntándonos ¿Es la única vía que conecta dos países? ¿Es la vía
> principal que conecta dos ciudades? ¿Es la única vía que permite acceder a
> un pueblo?
>
> Desde luego lo que hace falta es darle una revisión gorda a las carreteras
> añadiendo toda esa información de las características. Una tabla en el wiki
> con las carreteras por CCAA estaría guay tipo [0] para saber el estado.
> De hecho la página del wiki que te has currado puede servir en "sentido
> contrario" para indicar que etiquetas podrían ser interesantes para cada
> una de las vías.
>
> Desde luego si el gps te lleva por una primary que cruza pueblos si hay
> una secondary que va directa, la culpa es del gps por no tener en cuenta
> las etiquetas de velocidad, etc (o nuestra si no están los maxspeed...)
>
> [0]: https://wiki.openstreetmap.org/wiki/WikiProject_Spain/Autopista
>
> Saludos,
>   Alejandro Suárez
>
> 2016-05-04 18:47 GMT+02:00 David Marín Carreño <dav...@gmail.com>:
>
>> Hola a todos.
>>
>> Mi granito de arena sobre esta cuestión.
>>
>> Creo que el sistema actual de normalización está funcionando bien en
>> general, y que el problema viene dado en aquellas comunidades autónomas en
>> las que la administración ha hecho un uso alegre de sus potestades, y a una
>> misma carretera (con la misma nomenclatura, me refiero) le ha dado diversos
>> tratamientos según el tramo.
>>
>> Sin embargo, en la mayoría de comunidades esto no se ha hecho así, y
>> según el catálogo de carreteras de cada una de ellas se deja bien clara la
>> categorización de cada carretera, a la que suelen corresponderse ciertas
>> características físicas.
>>
>> Dicho lo cual, propongo dejar el sistema como está y poner las
>> excepciones pertinentes en las CC.AA. en las que existan los problemas que
>> comentáis.
>>
>> Un cordial saludo.
>> --
>> David Marín Carreño
>>
>> El mié., 4 may. 2016 a las 18:14, Diego García (<dgerv...@gmail.com>)
>> escribió:
>>
>>> Repasando todo un poco (aún no me he metido del todo "a fondo"), hay
>>> cosas que no me convencen:
>>>
>>> - La motorways: creo que tenemos todos claro lo que son en España:
>>> autovías. Si alguna vía no tiene referencia A-XX ó AP-XX (azul), pero tiene
>>> las características de una autovía, debería mapearse igualmente como
>>> motorway. Doble sentido de circulación, sin accesos a nivel ni a fincas, y
>>> máxima genérica de 120.
>>>
>>> - Las trunk: según la wiki, son las vías principales (que vertebran
>>> grandes zonas con otras y entre sí) y que no son autovías. En mi opinión,
>>> deberían ser todas las nacionales (radiales o no), porque esa es
>>> precisamente su función. Tienen salidas a nivel o excepcionalmente alguna
>>> que no, pero no es obligado, y genérica de 100km/h. Si la función de vía
>>> principal se ha perdido (porque hay una autovía que la suple, o porque otra
>>> carretera la ha asumido), debería bajar a primary, aunque tenga ref N-XX.
>>>
>>> No sigo con el resto de categorías, prefiero estudiar más a fondo el
>>> resto de la propuesta. Estas dos son las que primero he mirado de momento,
>>> y las que creo que más polémica generarán. Y, por supuesto, en lo que estoy
>>> totalmente de acuerdo es en que habría que hacer una buena revisión de lo
>>> que tenemos en el mapa: hay muchas vías que no merecen la highway que
>>

Re: [Talk-es] Propuesta de cambios en la normalización para las vías interurbanas

[Diego García]

Repasando todo un poco (aún no me he metido del todo "a fondo"), hay cosas
que no me convencen:

- La motorways: creo que tenemos todos claro lo que son en España:
autovías. Si alguna vía no tiene referencia A-XX ó AP-XX (azul), pero tiene
las características de una autovía, debería mapearse igualmente como
motorway. Doble sentido de circulación, sin accesos a nivel ni a fincas, y
máxima genérica de 120.

- Las trunk: según la wiki, son las vías principales (que vertebran grandes
zonas con otras y entre sí) y que no son autovías. En mi opinión, deberían
ser todas las nacionales (radiales o no), porque esa es precisamente su
función. Tienen salidas a nivel o excepcionalmente alguna que no, pero no
es obligado, y genérica de 100km/h. Si la función de vía principal se ha
perdido (porque hay una autovía que la suple, o porque otra carretera la ha
asumido), debería bajar a primary, aunque tenga ref N-XX.

No sigo con el resto de categorías, prefiero estudiar más a fondo el resto
de la propuesta. Estas dos son las que primero he mirado de momento, y las
que creo que más polémica generarán. Y, por supuesto, en lo que estoy
totalmente de acuerdo es en que habría que hacer una buena revisión de lo
que tenemos en el mapa: hay muchas vías que no merecen la highway que
tienen, y todos conocemos ejemplos de ello.



Y lo que para mí es lo más importante de todo, y en lo que apoyo todo mi
argumento: no trabajar (sólo) para el render. Me explico (y a ver si lo
consigo...;) ): una normalización en la que la calidad de la vía se expresa
en el key highway, sirve sólo para que se represente dicha calidad
gráficamente en el mapa. Si utilizamos para ello el resto de claves (ancho
de la via, número de carriles, velocidad de la vía, etc), estas
características no aparecerán en el mapnik, pero serán mucho más reales que
una sola clave (el tipo de vía). Es decir, si queremos un mapa que nos
visualice lo mal (o lo bien) que tenemos las carreteras en España,
tendremos que hacer un render que tenga en cuenta dichas etiquetas, y no la
etiqueta highway. Es más, en caso de no existir (ya me pierdo con tanta
etiqueta), habría que contemplar claves tales como arcén, estado del firme
o señalización horizontal. Eso nos daría una flexibilidad completa a la
hora de mapear, sean vías completas o tramos de ella, para cualquier tamaño
de dicho tramo.

Resumiendo: cuando el gps (o nosotros mismos) nos conduce por una vía no
debe fijarse en la clave highway para tomar decisiones (porque dicha clave
expresa función, no calidad), sino en claves tangibles, como el ancho de
vía, su velocidad, etc.



Un cordial saludo,

Diego.


El lun., 2 may. 2016 a las 19:42, Manuel Lladosa ()
escribió:

> Me parece una iniciativa genial, porque la verdad que habían carreteras
> "Trunk" en un estado bastante lamentable.
>
> En general lo veo todo bien, pero tengo una pregunta, con "enlaces a
> distinto/mismo nivel", ¿te refieres a cruces a distinto/mismo nivel? Así
> lo he entendido yo, pienso que la gente entenderá mejor la palabra
> cruces, por lo menos a mí la palabra enlace me sugiere incorporación a
> autovía.
>
> Un saludo.
>
> El 02/05/16 a les 14:00, talk-es-requ...@openstreetmap.org ha escrit:
> > Después de un proceso de debate con parte de la comunidad OSM de España
> > vía Telegram y de la necesidad de reformulación de la Normalización de
> vías
> > interurbanas os presento como quedaría en la wiki. Es un apartado de la
> > wiki que además de expresar las diversas categorías de la normalización
> > basada más en ser física que administrativa también tiene en cuenta las
> > diversas planificaciones de las administraciones que tienen competencias
> en
> > carreteras, desde gobiernos autonómicos a consejos insulares, algunas
> vías
> > de los cuales son modernas y por lo tanto pueden cumplir con categorías
> > físicas más importantes que las que les da una clasificación
> administrativa.
> >   El texto está abierto a debate, es inclusivo y requerirá de la
> > participación activa de la comunnidad ya que se se tienen en cuenta casos
> > específicos para determinados lugares con determinados usos (a más uso
> más
> > importancia ergo más categoría). Esperemos que esta nueva normalización
> > haga que nuestros mapas sean más reales y más útiles si cabe.
> >
> >   La dirección para consultarla es
> > http://wiki.openstreetmap.org/wiki/User:Yopaseopor y en un futuro
> ocupará
> > el apartado de vías interubanas y de comunidades autónomas de
> > http://wiki.openstreetmap.org/wiki/Normalizaci%C3%B3n
> >
> >   ¿Qué opinais? ¿Cómo lo veis? ¿Qué mejoraríais?
> >   Salud y Normalización
> >   Yopaseopor
> >
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Reunión OSM.es / IGN

[Diego García]

De acuerdo contigo Miguel. En la medida de mis posibilidades, contad
conmigo. Una de las cosas que suele echar atrás a los nuevos es
precisamente eso: cierta dispersión de esfuerzos, que se refleja en la wiki.


Un saludo,

El mar., 26 de abril de 2016 17:40, Miguel Sevilla-Callejo <
msevill...@gmail.com> escribió:

> Hola,
>
> Yo creo que si hay interés sólo que nadie ha liderado el asunto.
>
> Hace un par de semanas estuvimos reunidos en Zaragoza algunos de esta
> lista y hablamos sobre el tema y todos nos parecía necesaria la
> reactivación de OSM.es, no sólo para la colaboración con el IGN si no por
> la propia dinámica interna de los editores más activos.
>
> En aquella reunión nos preguntábamos quien tendría los papeles de la
> asociación y si podría hacerlos llegar a todos para moverlo.
>
> Yo, de hecho, pensé que algo habríais movido por Madrid.
>
> Por favor, quien tenga los papeles con la burocracia que se movió hace
> años que se manifieste y si pude compartirlo mejor.
>
> Por otro lado y como dije creo en este mismo hilo yo me puedo colaborar en
> la reactivación de OSM.es.  ¿Quién más se apunta?
>
> ¿Damos otro mes de plazo?
>
> Venga, decir algo. Aunque sea un "yo paso", un " quizá " o "contar
> conmigo".
>
> 
>
> --
> Miguel Sevilla-Callejo
> desde el móvil
> El 26/4/2016 16:37, "Jorge Sanz"  escribió:
>
> Hola,
>
> Han pasado casi dos meses y no ha habido más actividad a este respecto.
>
> Yo entiendo que *NO* hay interés en reflotar OSM.es y hay que dar una
> respuesta negativa y definitiva al IGN para no hacerles perder más el
> tiempo a ellos ni a nosotros.
>
> Si alguien no está de acuerdo con esto que proponga acciones concretas
> en espacio y tiempo.
>
> Saludos
>
> 2016-02-29 4:24 GMT-05:00 Jorge Sanz :
> > """
> >
> https://fomento.webex.com/fomento/onstage/g.php?MTID=ee157b227abfb9e697ff294a4de5577b3
> >
> > Desde las 11:00 estará la teleconferencia abierta, así que podéis
> > probar a conectaros, probar el audio y el vídeo, etc. A veces funciona
> > mejor con Explorer que con Firefox (lo siento). Reenviad este mensaje,
> > por favor, a quien deba estar en la reunión por el lado de OSM o
> > GeoInquietos.
> > """
> >
> >
> > 2016-02-29 10:21 GMT+01:00 Jorge Sanz :
> >> Hola, tenemos la reunión en un par de horas,
> >>
> >> ¿os parece quedar La llama[1], justo delante del IGN a las 11:30 y
> >> charlamos un poco antes?
> >>
> >> Por telegram me tenéis en el móvil como @xurxosanz
> >>
> >> Respecto al acceso en remoto no sé nada de ellos pero en cuanto nos
> >> den los datos informo por aquí.
> >>
> >> Saludos
> >>
> >> [1] http://www.openstreetmap.org/node/2580708153
> >>
> >> 2016-02-23 22:20 GMT+01:00 Manu El :
> >>> Hola de nuevo.
> >>>
> >>> Gracias por vuestros comentarios.
> >>>
> >>> El hecho de que en la reunión del próximo 29 esté alguien de WMES
> entiendo
> >>> que no debería "dispersar" las voces con los interlocutores. Al menos
> la
> >>> intención no es en absoluto esa. Sabemos que el protagonismo aquí la
> tiene
> >>> la comunidad de OSM y al final cualquier colaboración que pueda
> fructificar
> >>> dependerá de su movilización. Y es precisamente en esto en lo que creo
> que
> >>> podemos echar un cable gordo. El compañero que puede acudir, Rubén
> Ojeda,
> >>> lleva unos meses trabajando para WMES y se está ocupando de la
> coordinación
> >>> de programas a tiempo completo. Además él ya estuvo en la reunión que
> citaba
> >>> en el anterior correo con el IGN, la cual dio resultados positivos.
> Creo que
> >>> puede aportar bastante.
> >>>
> >>> Reflotar OSM.es suena genial -y dentro de mis posibilidades ayudaré,
> pero
> >>> solo en desarrollar y sostener la parte organizativa desde cero vamos a
> >>> destinar unos recursos que por pura lógica se detraerán del propio
> tiempo
> >>> que podríamos dedicar a sacar adelante actividades orientadas -por
> ejemplo-
> >>> a colaborar con el IGN o mismamente a mapear. Visto de otra manera: si
> el
> >>> IGN precisa de una asociación de OSM en España activa y funcional para
> poder
> >>> sacar adelante una colaboración con la comunidad de usuarios,
> interpreto que
> >>> por lo pronto deberá esperar unos ¿pocos, bastantes? meses hasta que
> ésta
> >>> sea una realidad.
> >>>
> >>> La otra opción que me parece más factible, en tanto en cuanto OSM.es va
> >>> tomando forma, es que se propongan lineas de colaboración que se
> apoyen en
> >>> grupos locales e informales de usuarios de OSM, geoinquietos y que
> cuenten
> >>> con el respaldo de WMES (u otras asociaciones que tengan por principio
> el
> >>> apoyo a iniciativas relacionadas con el conocimiento libre y que se
> >>> quisieran sumar).
> >>>
> >>> Un saludo.
> >>>
> >>>
> >>>
> >>> El 23 de febrero de 2016, 10:48, Jorge Sanz 
> escribió:
> 
>  2016-02-23 10:25 GMT+01:00 Miguel Sevilla-Callejo <
> msevill...@gmail.com>:
>  > Hola,
>  >
>  > Estoy totalmente de 

Re: [Talk-es] Fallo de verificación de función - Ruta GR-1

[Diego García]

Hola a todos.

Antes de que el tema se olvide, lo vuelvo a tomar de la mano. Quizá sirva
de ejemplo, y consigamos que el wiki se reactive, así como el trazado de
rutas por España.

Veo que la página
http://wiki.openstreetmap.org/wiki/WikiProject_Spain/Senderismo/GR-1 es lo
correcto. Nadie ha opinado nada más. Sobre su estructura, de todo lo
aportado creo que lo ideal es por provincias, y así lo voy a hacer. Si
existe división en etapas dentro de cada provincia, ya se aportará más
adelante.

Respecto al gpx, se puede descargar sin problemas; dividirlo por provincias
lo veo como sencillo, se puede hacer en un rato. Se colgará en la wiki para
su acceso, ya he visto como se hace.

Si alguien se pone a editar la GR-1, ojo: faltan tramos, Navarra y
Cantabria del todo, hay una variante sin documentar, y no me fío demasiado
del trazado que tenemos. Habrá que documentarse bastante, e incluso visitar
tramos para verificarla (ésta es la parte que más me gusta :) ).

Respecto al flujo de trabajo, está claro: *no hay que borrar la relación
actual del GR-1 en ningún momento*. Me remito a lo que dije en post
anterior: copiar, rehacer, comprobar, sustituir.

Por mi parte, me voy poniendo manos a la obra. Si cometo algún disparate
(con el wiki o con lo que sea), espero que alguien me lo diga. La
ignorancia es muy atrevida.




Un cordial saludo,

pd.: he visto un hilo paralelo a éste, en el que uno de los editores que
participaron en el GR1 en sus inicios se llegaba a disculpar por su estado.
Creo que la contestación que le han dado expresa perfectamente lo que
siento. Posiblemente si no fuera por tí y tus compañeros en aquel momento,
ahora no estaríamos haciendo esto. Recibe toda mi admiración y mis respetos
por vuestro trabajo. ¡Gracias!



El mar., 8 mar. 2016 a las 22:21, Alejandro S. (<alejandro...@gmail.com>)
escribió:

> Me parece que la pagina en
> http://wiki.openstreetmap.org/wiki/WikiProject_Spain/Senderismo/GR-1 está
> bien, sino tendría que ser
> http://wiki.openstreetmap.org/wiki/Spanish_hiking_route_GR-1 o algo por
> el estilo.
>
> En cuanto a la tabla parece que hay un plantilla para marcar el estado:
> {{State Hiking|}} [0] Se pude tomar como ejemplo [1]
>
> No es compatible ya que al no poner bajo que licencia se publica, está
> protegido por lo derecho de autor, además parece que es información que
> esta en wikiloc, que tampoco es compatible con la odbl.
>
> Cuando el proceso esté terminado la relación actual del GR-1 tendrá como
> miembros únicamente las subrutas.
>
>
> [0]: http://wiki.openstreetmap.org/wiki/Template:State_Hiking
> [1]: http://wiki.openstreetmap.org/wiki/European_long_distance_path_E4
>
> Atentamente,
>   Alejandro Suárez
>
> 2016-03-08 21:16 GMT+01:00 Diego García <dgerv...@gmail.com>:
>
>> De acuerdo, Santi. No sé si lo correcto es hacer una página en
>> http://wiki.openstreetmap.org/wiki/WikiProject_Spain/Senderismo/GR-1, o
>> en http://wiki.openstreetmap.org/wiki/GR-1, a ver qué dicen los
>> expertos, especialmente Miguel Sevilla-Callejo, que ha manifestado interés
>> en este asunto.
>>
>> Allí se divide el GR en provincias, se pone la típica tabla para que se
>> apunten voluntarios para revisar y marcar lo que hay hecho y ponemos
>> también las etapas por cada provincia, para que no queden relaciones
>> demasiado grandes si se trabaja por provincias únicamente. Cada etapa, una
>> relación (o lo que decidamos, espero opiniones). Por lo que he visto, es un
>> trazado continuo hasta llegar a Asturias, en donde no hay nada definido.
>> Luego salta a Galicia. Lo que no tengo claro es lo de bajar el gpx y luego
>> colgar los trozos. ¿En dónde? Me imagino que en la propia wiki, eso no sé
>> hacerlo.
>>
>> El flujo de trabajo que había pensado es:
>> - Conseguir el gpx de un tramo. Si es de una fuente fiable en vez de lo
>> que tenemos en OSM, mejor. Por ejemplo, aquí tienen los tramos
>> http://gr1.branosera.com/index.php?m=etapas Aquí tengo una duda: ¿es
>> compatible utilizar esos GPX como superposición en JOSM para revisar la
>> ruta?
>> - Con el JOSM, duplicar la relación "madre" del GR1, y en el duplicado
>> borrar los trozos que sobren respecto al tramo a revisar. Este duplicado
>> será la nueva relación.
>> - Superpuesto el GPX, revisar el tramo
>> - Por último, en la relación del GR1, borrar los trozos que ya no sirven
>> y sustituirlos por la nueva relación.
>>
>> A ver si, poco a poco, conseguimos relanzar el tema del wiki.
>>
>>
>> Un saludo,
>>
>>
>> El mar., 8 mar. 2016 a las 19:27, Santi Aguirre (<aguirrera...@gmail.com>)
>> escribió:
>>
>>> Hola,
>>>
>>> Estoy de acuerdo con Alejandro en convertir la relación actua

Re: [Talk-es] Fallo de verificación de función - Ruta GR-1

[Diego García]

De acuerdo, Santi. No sé si lo correcto es hacer una página en
http://wiki.openstreetmap.org/wiki/WikiProject_Spain/Senderismo/GR-1, o en
http://wiki.openstreetmap.org/wiki/GR-1, a ver qué dicen los expertos,
especialmente Miguel Sevilla-Callejo, que ha manifestado interés en este
asunto.

Allí se divide el GR en provincias, se pone la típica tabla para que se
apunten voluntarios para revisar y marcar lo que hay hecho y ponemos
también las etapas por cada provincia, para que no queden relaciones
demasiado grandes si se trabaja por provincias únicamente. Cada etapa, una
relación (o lo que decidamos, espero opiniones). Por lo que he visto, es un
trazado continuo hasta llegar a Asturias, en donde no hay nada definido.
Luego salta a Galicia. Lo que no tengo claro es lo de bajar el gpx y luego
colgar los trozos. ¿En dónde? Me imagino que en la propia wiki, eso no sé
hacerlo.

El flujo de trabajo que había pensado es:
- Conseguir el gpx de un tramo. Si es de una fuente fiable en vez de lo que
tenemos en OSM, mejor. Por ejemplo, aquí tienen los tramos
http://gr1.branosera.com/index.php?m=etapas Aquí tengo una duda: ¿es
compatible utilizar esos GPX como superposición en JOSM para revisar la
ruta?
- Con el JOSM, duplicar la relación "madre" del GR1, y en el duplicado
borrar los trozos que sobren respecto al tramo a revisar. Este duplicado
será la nueva relación.
- Superpuesto el GPX, revisar el tramo
- Por último, en la relación del GR1, borrar los trozos que ya no sirven y
sustituirlos por la nueva relación.

A ver si, poco a poco, conseguimos relanzar el tema del wiki.


Un saludo,


El mar., 8 mar. 2016 a las 19:27, Santi Aguirre (<aguirrera...@gmail.com>)
escribió:

> Hola,
>
> Estoy de acuerdo con Alejandro en convertir la relación actual en una
> super relación. Si hubiera consenso en hacerlo de esa manera tengo una
> propuesta para editarla:
>
> 1) Descargar de waymarkedtrails la relación en formato gpx y trocear la
> traza por provincias para que sirva como plantilla al editar en JOSM. Así
> nos asegurarnos de que el trazado de la ruta es el mismo.
> 2) Trocear también la relación actual en provincias (o intentarlo al menos
> porque hay zonas con saltos muy grandes) y mantenerlos como subtramos
> dentro de la super relación.
> 3) Voluntarios que editen/vacíen/rehagan los subtramos.
>
> Estoy dispuesto a encargarme de los puntos 1 y 2 y colaborar en el 3.
> Haría falta un voluntario que se maneje en la wiki para crear una entrada
> y poner los enlaces a los gpx.
>
> ¿Que os parece?
>
> Un saludo
>
> El 8 de marzo de 2016, 10:41, Alejandro S. <alejandro...@gmail.com>
> escribió:
>
>> Buenas,
>> José Luis tiene razón, no podemos ir borrando elementos solo porque nos
>> parezca que no están bien. Por ejemplo wikidata hace referencia a la
>> relación de OSM [0] y si se borra complica la existencia a todo el que la
>> use. Yo creo lo suyo es convertir la relación actual en la super relación
>> que contenga los subtramos, y se añada una etiqueta note explicando la
>> decisión tomada, de esta forma además se conserva el historial de la
>> relación.
>>
>> Saludos,
>> Alejandro Suárez
>>
>> [0]: https://m.wikidata.org/wiki/Q13108091
>>
>> On Mon, Mar 7, 2016, 21:16 José Luis Domingo López <
>> openstreetm...@24x7linux.com> wrote:
>>
>>> El lunes día 07 de marzo de 2016, a las 20:36:30 +0100,
>>> Diego García escribió:
>>>
>>> > Me parece que la forma correcta de proceder no sería borrar la
>>> relación y
>>> > empezar de cero, sino coger un tramo, crear una relación nueva
>>> revisando
>>> > dicho tramo, y sustituir en la relación ya existente del GR1 los tramos
>>> > revisados por la nueva relación.
>>> >
>>> Aunque participo muy poco (nada) recientemente, me uno a la opinión de
>>> Diego en relación a mantener la relación actual, y sanearla, aunque sea
>>> vaciándola completamente y añadiendo todo de golpe.
>>>
>>> Quizás no sea formalmente correcto ni recomendado, pero yo le veo
>>> utilidad
>>> a mantener el ID de la relación a una ruta una vez creada, aunque haya
>>> que
>>> hacerle un trabajo de reparación tan serio como éste parece. Si queremos
>>> que OSM sea una referencia perdurable y fiable, no podemos andar
>>> cambiándole al resto del mundo el ID de la relación de algo tan masivo y
>>> de
>>> tan largo alcance como un GR.
>>>
>>> Otra cosa que recomendaría es, pensar que no todo el que edita en OSM es
>>> asiduo de la lista ni mucho menos consulta una wiki en particular antes
>>> de
>>> meterle mano al mapa. Si hay la previsión de modifica

Re: [Talk-es] Fallo de verificación de función - Ruta GR-1

[Diego García]

Buscando un poco más de información, voy viendo más detalles. Sí existe una
división por provincias y, a su vez, por tramos del GR-1. Además, acabo de
leer que el tramo de Asturias no está trazado, y que el Gallego, realmente,
tampoco.

Me parece que la forma correcta de proceder no sería borrar la relación y
empezar de cero, sino coger un tramo, crear una relación nueva revisando
dicho tramo, y sustituir en la relación ya existente del GR1 los tramos
revisados por la nueva relación.



Un saludo,

El 7 de marzo de 2016, 19:10, Diego García <dgerv...@gmail.com> escribió:

> Totalmente de acuerdo, sólo habría que discutir los detalles.
>
> Otras rutas tienen una división diferente: por tramos que tengan algún
> nexo en común tipo cultural, paisaje, etc. Esta ruta veo que no tiene
> tramos claros definidos; las divisiones que encuentro son por provincias
> [1], excepto la propuesta por esta otra página [2], que creo que limita por
> distancia. A elegir. Por llevar la contraria, y por no terminar otra vez
> con relaciones de tropecientos miembros, yo votaría por la segunda, incluso
> siguiendo esa propuesta concreta de etapas.
>
> Propongo colgarlo en la wiki (ahora que ya sé cómo se hace :D ), repartir
> la faena (yo puedo hacer los tramos de Huesca, y luego ir cogiendo los que
> vayan quedando cerca sin hacer), y ponernos manos a la obra. En este punto
> hay dos formas de hacerlo: borrar la relación y empezar de cero, o dejarla
> un tiempo para hacer una copia, quitándole a cada copia que se haga los
> tramos que sobran, para así sólo tener que revisar. Me gusta más empezar de
> cero.
>
> A la espera de más opiniones, un cordial saludo,
>
>
> [1] http://www.fam.es/senderos/gran-recorrido/gr-1
> https://es.wikipedia.org/wiki/GR-1
> [2] http://gr1.branosera.com/index.php?m=etapas
>
>
>
>
> El lun., 7 mar. 2016 a las 18:37, Santi Aguirre (<aguirrera...@gmail.com>)
> escribió:
>
>> Hola,
>>
>> He echado un vistazo al GR y me he encontrado con zonas de la relación
>> que están hechas un desastre. Tanto que no se si convendría, más que
>> arreglarla, empezar de cero. Razón:
>> - Está compuesta de 1858 miembros (y eso que aún no está terminada) lo
>> cual complica mucho los arreglos.
>> - Las buenas prácticas aconsejan no crear relaciones de más de 250/300
>> miembros [1]. Propongo hacer relaciones más pequeñas (¿una por cada
>> provincia que atraviese?) y luego unirlas con una superrelación.
>> - Se me ocurre (no sé si es buena práctica jeje!) que podríamos descargar
>> el gpx, eliminar la relación actual que creo que sirve de poco y con el gpx
>> como base volver a hacerla por tramos.
>>
>> Es una sugerencia... ;)
>>
>> Un saludo
>>
>>
>> [1] http://wiki.openstreetmap.org/wiki/Relation:route#Size
>>
>> El 6 de marzo de 2016, 11:54, Miguel Sevilla-Callejo <
>> msevill...@gmail.com> escribió:
>>
>>> Anda, pues justo en la Hoya de Huesca quería meterle mano yo! Pero no
>>> precisamente en el GR-1 si no para marcar igualmente el "camino natural"
>>> que no responde a las homologaciones de la Federación de Montaña si no una
>>> "nueva" competencia del ministerio...
>>>
>>> Si, yo decía meterle mano primero a la wiki de senderismo y también
>>> dividir competencias/responsabilidades entre los voluntarios.
>>>
>>> A la espera de más comentarios quedamos...
>>>
>>> Un saludos
>>>
>>> --
>>> Miguel Sevilla-Callejo
>>> desde el móvil
>>> El 6/3/2016 9:55, "Diego García" <dgerv...@gmail.com> escribió:
>>>
>>>> Ahí le has dao: tenemos pendiente mover la wiki. Como ya dije en el
>>>> correo que abriste, cuenta conmigo, aunque no veo la forma de coordinarnos.
>>>> Quizá haciendo una división territorial por un lado, y otra temática por
>>>> otro, buscando voluntarios que se responsabilicen de cada una... No lo sé.
>>>>
>>>> Te haré caso; voy a dejar pasar unos días, y luego corregiré lo que vea
>>>> mal en la relación. Después, revisaré todo el tramo que cruza por la zona
>>>> que trabajo, que es la comarca de la Hoya de Huesca, y dejaré constancia en
>>>> la wiki.
>>>>
>>>> Por cierto, no veo creada ninguna página sobre la GR-1 (ni para ninguna
>>>> otra GR), supongo que te refieres a la dedicada al senderismo. No me manejo
>>>> muy bien con las wiki, ya que desconozco lo que es correcto hacer y lo que
>>>> no: ¿escribo en la discusión de la página, o en el cuadro de observaciones
>>>> de la GR? Lo que sí t

Re: [Talk-es] Fallo de verificación de función - Ruta GR-1

[Diego García]

Ahí le has dao: tenemos pendiente mover la wiki. Como ya dije en el correo
que abriste, cuenta conmigo, aunque no veo la forma de coordinarnos. Quizá
haciendo una división territorial por un lado, y otra temática por otro,
buscando voluntarios que se responsabilicen de cada una... No lo sé.

Te haré caso; voy a dejar pasar unos días, y luego corregiré lo que vea mal
en la relación. Después, revisaré todo el tramo que cruza por la zona que
trabajo, que es la comarca de la Hoya de Huesca, y dejaré constancia en la
wiki.

Por cierto, no veo creada ninguna página sobre la GR-1 (ni para ninguna
otra GR), supongo que te refieres a la dedicada al senderismo. No me manejo
muy bien con las wiki, ya que desconozco lo que es correcto hacer y lo que
no: ¿escribo en la discusión de la página, o en el cuadro de observaciones
de la GR? Lo que sí tengo claro es que voy a actualizar las PR y senderos
locales de mi zona que llevo hechas, que son unas cuantas.

Muchas gracias, un saludo,



El sáb., 5 mar. 2016 a las 22:14, Miguel Sevilla-Callejo (<
msevill...@gmail.com>) escribió:

> Ufff, el GR-1...
>
> Yo ya hace tiempo que había detectado diversos fallos, entre ellos que por
> algunos lugares no está bien el trazado (por ejemplo al N de la Sierra de
> Guará, en Huesca) pero tampoco me atreví a meterle mano.
>
> Tenemos pendiente mover la Wiki y yo llevó meses con un correo a medias
> para hacer una propuesta para el apartado de senderismo y rutas.
>
> Yo te diría que tirarás para adelante pues es mejor medio-arreglar que
> dejar las cosas mal pero me esperaría a ver que te dicen otros
> colaboradores más "ilustres" al respecto.
>
> Al fin y al cabo dejaste registro aquí del problema y si lo comentas en la
> wiki ya sería de nota.
>
> Un saludo y a la espera de que dicen otros.
>
> --
> Miguel Sevilla-Callejo
> desde el móvil
> El 5/3/2016 10:02, "Diego García" <dgerv...@gmail.com> escribió:
>
>> Buenos días.
>>
>> Editando un área cercana me he tropezado con la relación de la ruta GR-1,
>> que pasa por esa zona. Al validar los datos antes de subirlos con JOSM, me
>> ha aparecido un error de función en varios tramos.
>>
>> La relación es una ruta de senderismo (route=hiking). Por lo que sé, los
>> tramos que la componen no deberían llevar nada en el role. Sin embargo, una
>> buena parte de estas vías han sido etiquetadas en el role como "León",
>> "Palencia", etc, a su paso por esas provincias; es decir, creo que se ha
>> aprovechado ese dato para definir tramos en la relación, y no es la forma
>> correcta de hacerlo. El osmose me reporta casi 300 errores sobre ello.
>>
>> No estoy seguro al 100% sobre este tema, la relación es muy grande, y no
>> se puede descargar el historial (da un error de time out) para avisar al
>> autor, así que prefiero preguntar antes de tocar nada: ¿este etiquetado es
>> correcto? ¿alguien sabe algo sobre el tema? ¿me lío la manta a la cabeza y
>> corrijo lo que creo que es un error?
>>
>> Cuando me encuentro con estos temas, más veo la necesidad de
>> organizarnos, apañar en condiciones la wiki, decidir criterios que sigamos
>> todos, ... Si yo que llevo un tiempo metido en esto tengo dudas, no quiero
>> pensar en los que empiezan ahora.
>>
>> Por cierto, la relación es la
>> http://www.openstreetmap.org/relation/1307422 Es el "Sendero histórico",
>> que cruza todo el norte de España de lado a lado.
>>
>>
>>
>> Un saludo a todos,
>>
>>
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[Talk-es] Fallo de verificación de función - Ruta GR-1

[Diego García]

Buenos días.

Editando un área cercana me he tropezado con la relación de la ruta GR-1,
que pasa por esa zona. Al validar los datos antes de subirlos con JOSM, me
ha aparecido un error de función en varios tramos.

La relación es una ruta de senderismo (route=hiking). Por lo que sé, los
tramos que la componen no deberían llevar nada en el role. Sin embargo, una
buena parte de estas vías han sido etiquetadas en el role como "León",
"Palencia", etc, a su paso por esas provincias; es decir, creo que se ha
aprovechado ese dato para definir tramos en la relación, y no es la forma
correcta de hacerlo. El osmose me reporta casi 300 errores sobre ello.

No estoy seguro al 100% sobre este tema, la relación es muy grande, y no se
puede descargar el historial (da un error de time out) para avisar al
autor, así que prefiero preguntar antes de tocar nada: ¿este etiquetado es
correcto? ¿alguien sabe algo sobre el tema? ¿me lío la manta a la cabeza y
corrijo lo que creo que es un error?

Cuando me encuentro con estos temas, más veo la necesidad de organizarnos,
apañar en condiciones la wiki, decidir criterios que sigamos todos, ... Si
yo que llevo un tiempo metido en esto tengo dudas, no quiero pensar en los
que empiezan ahora.

Por cierto, la relación es la http://www.openstreetmap.org/relation/1307422
Es el "Sendero histórico", que cruza todo el norte de España de lado a lado.



Un saludo a todos,
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] POSIBLE IMPORTACIÓN DE DATOS DEL IGN.

[Diego García]

Soy de la misma opinión. No me gustan las importaciones masivas, lo único
que se consigue es añadir los errores que precisamente se intentan evitar
con OSM. Está muy bien como punto de comienzo en una zona que no está
cartografiada, pero no a gran escala, ni en zonas ya trabajadas. Eso sí,
como apoyo al trabajar una zona pequeña, es una ayuda inestimable.

Un saludo,

El 5 de marzo de 2016, 8:30, Pedro-Juan Ferrer Matoses 
escribió:

> Hola,
>
> la política general de la comunidad OSM española es no hacer importaciones
> masivas y dentro de lo que cabe hay que respetarla.
>
> Es posible que se pudiera hacer importación masiva de cosas que ahora no
> existan a nivel nacional, pero para el resto, la comunidad prefiere revisar
> caso por caso en zonas pequeñas.
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Ubicación de los números de las porterías

[Diego García]

Es cierto que la solución parece estar lejos. Por mi parte, lo venía
observando desde no hace muchos meses, debido a que osmose muestra como
errores los números duplicados que se producen, y justo este fin de semana
se me ocurrió una posible solución, que decidí probar:

La dirección real de una tienda que está en los bajos de un edificio, no es
el número de portal de ese edificio, sino algo así como "número 2, bajo".
De este modo, coloco el punto con la dirección del portal donde
corresponde, a su entrada, y en el tag addr:housenumber de la tienda
etiqueto el número y le añado "bajo". El tag lo admite (osmose daría error
si dicho tag no comienza por un número), y leida la dirección completa es
totalmente correcta: Avenida de los Pirineos 15, bajo. Y el wiki parece que
no se opone a ello, aunque mi inglés es lamentable.

Como en Huesca tenemos la mayoría de tiendas y comercios sin poner su
dirección, he aprovechado para probarlo este fin de semana en los que sí la
tenían y además estaban reportando el error de numeración duplicada de
osmose. No son muchas, unas veinte, por lo que en caso de chapuza lo tengo
fácil para dar marcha atrás. Con nominatim funciona, y osmose no reporta
error:

- Si busco el nombre de la tienda, sale, y me ofrece su dirección completa
y real. Por ejemplo "restaurante martín viejo, huesca", daría "Restaurante
Martín Viejo, 15 bajo, Avenida de los Pirineos, Barrio de Santiago, Huesca,
Aragón, 22004, España" 
- Si busco la dirección, nominatim me ofrece como soluciones el propio
portal y los comercios que coinciden: "avenida de los pirineos, 15, huesca"
saca el mismo resultado de antes, y además añade "Casa 15, Avenida de los
Pirineos, Barrio de Santiago, Huesca, Aragón, 22004, España"

Como extrapolación, un comercio situado en la planta primera del número
siete (por poner un ejemplo), se etiquetaría como "7 piso 1", y seguiría
funcionando de la misma manera.

La segunda parte viene cuando hay varios comercios en un mismo edificio.
Aquí le he echado algo de imaginación, y he etiquetado como "local 1",
"local 2", etc. Lo cierto es que son direcciones reales (dentro de un mismo
edificio los locales comerciales suelen numerar de esa forma), pero de no
ser que entremos a preguntar al comerciante, desde la calle no vemos esa
información. En nominatim sigue funcionando bien: "avenida de monreal, 7,
huesca"

En general, como solución no me parece mala, aunque no me acaba de gustar
por dos motivos: el tag addr:housenumber ¿debe limitarse al número de
portal, o está permitida la extensión de su significado a más datos, como
el número de planta? ¿habría que tirar del tag addr:place?. Y en segundo
lugar, está lo de los multiples comercios en el mismo número, que no deja
de ser una dirección "inventada", a no ser que entre tienda por tienda a
preguntar el número de local.


Un cordial saludo,


El lun., 8 feb. 2016 a las 12:18, Jorge Sanz Sanfructuoso (<
sanc...@gmail.com>) escribió:

> Es otra de las cosas que no hay consenso. Nominatim si lo tiene en cuenta
> y si una tienda esta dentro de un edificio que tiene puesto el área del
> edificio la numeración la coge del edificio ( si la tienda no tiene
> numeración propia claro).
> Pero claro para eso se tendría que poner numeración al edificio y no a la
> entrada del edificio. Cosa que tampoco hay consenso, pero por aquí la
> mayoría parece que prefiere ponerlo a la entrada y no al área del edificio.
> Yo actualmente los estoy poniendo a la entrada normalmente.
>
> Es por una de las cosas que yo defiendo más el método de etiquetar la
> numeración en el área del edificio cuando sea posible. Igualmente tampoco
> es perfecto porque un edificio si da para 3 calles en 2 calles te toca
> poner igualmente la numeración de los locales si o si. También hay casos
> que el edificio tiene por ejemplo numeración del 10-20 y una tienda coge el
> número 10, otro el 16 y otro el 20 por lo que estás en las mismas. No hay
> una solución que arregle todos los casos y veo difícil que exista.
>
> Resumiendo, si el área del edificio tiene numeración por lo menos con
> nominatim no hace falta ponerlo en la tienda, habría que comprobarlo con
> otros programas. Si no es así hay que ponerle numeración a la tienda si o
> si y pasaría lo que has comentado.
>
> El lun., 8 feb. 2016 a las 11:55, Alejandro Moreno Calvo (<
> almo...@gmail.com>) escribió:
>
>> Reabro este tema ya que me ha surgido la duda de como mapear edificios
>> que tienen tiendas todos con el mismo número de portal. Es decir, tengo un
>> edificio con varios nodos, uno corresponde a la entrada a las viviendas y
>> los otros de entradas a tiendas que hay dentro del edificio.
>> Si se pone el número de portal al edificio, ¿se asume que los nodos de
>> ese edificio tienen ese número de portal?
>> Lo que he visto hasta ahora en Madrid es edificios con esta casuística
>> tienen repetido por cada nodo el número de portal y el "problema" de esto
>> es que en programas 

Re: [Talk-es] Ubicación de los números de las porterías

[Diego García]

Coincidimos en descartar cosas como "local 1", "local 2". No se corresponde
a la realidad, y es un dato que, en la práctica, sería casi imposible de
conseguir.

Veo que está aprobado addr:floor, hoy cambiaré alguno y mañana comprobaré
si osmose sigue con sus números de portal repetidos. De momento, veo que
nominatim lo descarta y no lo utiliza en la búsqueda, aunque saca todos los
resultados bien para ese número de calle.


Saludos,

El 8 de febrero de 2016, 19:57, Jorge Sanz Sanfructuoso <sanc...@gmail.com>
escribió:

>
>
> El lun., 8 feb. 2016 a las 18:56, Diego García (<dgerv...@gmail.com>)
> escribió:
>
>> Es cierto que la solución parece estar lejos. Por mi parte, lo venía
>> observando desde no hace muchos meses, debido a que osmose muestra como
>> errores los números duplicados que se producen, y justo este fin de semana
>> se me ocurrió una posible solución, que decidí probar:
>>
>> La dirección real de una tienda que está en los bajos de un edificio, no
>> es el número de portal de ese edificio, sino algo así como "número 2,
>> bajo". De este modo, coloco el punto con la dirección del portal donde
>> corresponde, a su entrada, y en el tag addr:housenumber de la tienda
>> etiqueto el número y le añado "bajo". El tag lo admite (osmose daría error
>> si dicho tag no comienza por un número), y leida la dirección completa es
>> totalmente correcta: Avenida de los Pirineos 15, bajo. Y el wiki parece que
>> no se opone a ello, aunque mi inglés es lamentable.
>>
>
> Existe "addr:floor" que se supone que es para poner la planta, o también
> "level". La primera esta como propuesta pero no se cual sera mas adecuada.
> "level" es más usada. No creo que la tengan en cuenta los diferentes
> programas para hacer la dirección. Habría que comprobarlo.
>
>>
>> Como en Huesca tenemos la mayoría de tiendas y comercios sin poner su
>> dirección, he aprovechado para probarlo este fin de semana en los que sí la
>> tenían y además estaban reportando el error de numeración duplicada de
>> osmose. No son muchas, unas veinte, por lo que en caso de chapuza lo tengo
>> fácil para dar marcha atrás. Con nominatim funciona, y osmose no reporta
>> error:
>>
>> - Si busco el nombre de la tienda, sale, y me ofrece su dirección
>> completa y real. Por ejemplo "restaurante martín viejo, huesca", daría
>> "Restaurante Martín Viejo, 15 bajo, Avenida de los Pirineos, Barrio de
>> Santiago, Huesca, Aragón, 22004, España"
>> <http://www.openstreetmap.org/node/2538194434>
>> - Si busco la dirección, nominatim me ofrece como soluciones el propio
>> portal y los comercios que coinciden: "avenida de los pirineos, 15, huesca"
>> saca el mismo resultado de antes, y además añade "Casa 15, Avenida de los
>> Pirineos, Barrio de Santiago, Huesca, Aragón, 22004, España"
>>
>> Como extrapolación, un comercio situado en la planta primera del número
>> siete (por poner un ejemplo), se etiquetaría como "7 piso 1", y seguiría
>> funcionando de la misma manera.
>>
>> La segunda parte viene cuando hay varios comercios en un mismo edificio.
>> Aquí le he echado algo de imaginación, y he etiquetado como "local 1",
>> "local 2", etc. Lo cierto es que son direcciones reales (dentro de un mismo
>> edificio los locales comerciales suelen numerar de esa forma), pero de no
>> ser que entremos a preguntar al comerciante, desde la calle no vemos esa
>> información. En nominatim sigue funcionando bien: "avenida de monreal, 7,
>> huesca"
>>
>
> Lo de local 1, local 2 para una zona comercial si lo veo pero a pie de
> calle pu, ni el que tiene el local lo sabe. Tampoco se usa cuando se
> mandan cartas, se pone el numero el nombre del comercio y si acaso que es
> el bajo. El número de local es raro, por lo mismo. Al final toca
> inventarselo cosa que descarto hacer. Además para esto se usa "addr:door"
> si no me equivoco.
>
>>
>> En general, como solución no me parece mala, aunque no me acaba de gustar
>> por dos motivos: el tag addr:housenumber ¿debe limitarse al número de
>> portal, o está permitida la extensión de su significado a más datos, como
>> el número de planta? ¿habría que tirar del tag addr:place?. Y en segundo
>> lugar, está lo de los multiples comercios en el mismo número, que no deja
>> de ser una dirección "inventada", a no ser que entre tienda por tienda a
>> preguntar el número de local.
>>
>
> Yo entiendo que se limita al número del portal pero tampoco está claro.
> Podría darse el u

Re: [Talk-es] Marcado de centros de salud

[Diego García]

Pues no sólo tienes razón, si no que además estás en lo cierto. Eso explica
porqué tengo la mitad de una manera y el resto de otra: antes leía más la
wiki. Me toca revisar a mi también.

Un saludo

El lun 18/01/2016, 17:36, Alejandro Moreno Calvo <almo...@gmail.com>
escribió:

> Yo amenity=doctors lo use para consultas de dentistas, fisioterapeutas y
> cosas así. Buscando en la wiki veo que en la página
> http://wiki.openstreetmap.org/wiki/ES:Map_Features#Salud ya está marcado
> amenity:clinic para centros de salud así que voy a revisar los
> amenity:hospital de Madrid para ver cuales corresponden a ambulatorios y
> deben ser amenity:clinic
>
> El 15 de enero de 2016, 21:30, Diego García <dgerv...@gmail.com> escribió:
>
>> Yo no sé si estaré haciendo lo correcto, pero los centros de salud los
>> estoy etiquetando como amenity doctors.
>>
>> Tanto las clínicas como los hospitales son sitios en los que se puede
>> ingresar un enfermo para ser tratado, es decir, tienen habitaciones y
>> plantas para esa práctica. A diferencia de los centros de salud, en donde
>> hay una serie de consultas donde pasan visita diversos doctores, (o salas
>> de cura, urgencias, etc), pero no hay camas para ingresos. Por eso pienso
>> se ajusta más a amenity doctors.
>>
>>
>>
>> Un saludo,
>>
>>
>> El 12 de enero de 2016, 18:05, Alejandro Moreno Calvo <almo...@gmail.com>
>> escribió:
>>
>>> Revisando datos veo que en Madrid la mayoría de centros de salud y de
>>> especialidades están marcados como amenity:hospital
>>> Yo creo que debería ser amenity:clinic
>>> ¿Hay alguna normativa para estos centros?
>>>
>>> ___
>>> Talk-es mailing list
>>> Talk-es@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-es
>>>
>>>
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Fwd: Comparativa imágenes Bing y PNOA

[Diego García]

Hola Miguel, y buenas tardes a todos en general.

En primer lugar, me presento, ya que escribo muy poco por estas listas de
correo: me llamo Diego, y llevo ya algunos años dedicando tiempo a esto de
los mapas como afición, coincidiendo con la compra del gps y la bicicleta
de montaña al uso. Muchos se verán reflejados en esta historia :)

Quiero decirte que la explicación que has ofrecido en este post me ha
sorprendido agradablemente. Primero por lo clara e interesante y, sobre
todo, por exponer un problema del que no son conscientes muchos de los que
se lanzan a esta bonita aventura de *mapear *el mundo. En mis inicios, me
dedicaba a trazar mis propios mapas con Compe para utilizar con el gps y la
bici, harto de la falta de exactitud (por no decir otra cosa) de los mapas
disponibles. En un momento dado, descubrí los datos que pone a disposición
del público el CNIG y con ellos, la rejilla del LIDAR. Tras generar las
curvas de nivel, ví un desfase tremendo en algunas zonas de montaña
respecto a las ortofotos del PNOA, concretamente en el Salto del Roldán, al
norte de Huesca. También se puede apreciar en otras partes altas de la
sierra. Desde entonces me sigo apoyando en el PNOA para dibujar, pero
siempre visitando la zona gps en mano antes o después. Creo que es la forma
correcta de hacerlo, y que debería ser la práctica a seguir, especialmente
por los que empiezan.

Por otro lado, te puedo poner un ejemplo que me ha sucedido hoy mismo: en
una zona de Huesca en la que tracé los edificios y calles hace algunos
meses, he visto que un usuario había comenzado a etiquetar talleres. La
sorpresa ha sido grata (no *mapea *demasiada gente por aquí), pero me he
dado cuenta que se veían cosas raras en el render. Al echar un vistazo con
el JOSM, descubro edificios solapados, fuera de lugar, calles cortadas en
dos... y que en el *changeset *el usuario declaraba usar iD y Bing.
Efectivamente: antes de corregir, puse la capa de Bing y puede comprobar
que se ajustaba perfectamente a los errores que había introducido el
usuario en cuestión. Es una zona en la que ya he comprobado con el gps que
tanto el catastro como PNOA "aciertan", así que he corregido lo que he
visto fuera de sitio. No entiendo este tipo de ediciones: sin conocer la
zona, con herramientas dudosas (como el Bing, a no ser que lo ajustes
correctamente en JOSM), y estropeando trabajo de los demas. Aunque no me
enfada (aquí todos aprenden, por mucho tiempo que lleven, y yo el primero),
reconozco que algo de disgusto sí que produce.

Suerte con el curso que estás dando, no sé si ya habrá terminado. Veo de
vez en cuando ediciones por aquí, cerca de Huesca, con etiquetas #osmzgz15,
y espero ver más en lo sucesivo ;) El año que viene esperamos movernos algo
por Huesca, con algún mapping party y, puede, que un curso-taller.

Recibe un cordial saludo,

Diego.

https://wiki.openstreetmap.org/wiki/Huesca

El mié., 25 nov. 2015 a las 13:13, Miguel Sevilla-Callejo (<
msevill...@gmail.com>) escribió:

> (Reenvio email que olvidé quitar adjuntos en el anterior)
>
> Hola a todos,
>
> Con motivo de la preparación del curso sobre OSM que estoy impartiendo con
> la inestimable ayuda de Alejandro Suárez (@alejandroscf) en Zaragoza [1] he
> estado contrastando y preparando material gráfico para mis presentaciones
> [2] y que he compartido en el grupo de Telegram y he colgado en imagur.com
> [3].
>
> Os pego aquí lo que he dicho por esa vía:
>
> La imagen de Escuaín y que es de las mismas coordenadas habla por sí sola:
> existe una error de casi 50m entre una imagen Bing y la del PNOA en el área
> edificada. Las líneas negras que se observan son del Catastro (que
> conincide con el PNOA).
>
> Entonces Jonás ha comentado que "esto puede pasar con todos los WMS" y no
> he podido más que contestar argumentando que los errores están derivados de
> la corrección fotogramétrica de las imágenes y he continuado con lo
> siguiente (corto y pego del grupo de Telegram):
>
> La ortorectificación fotogramétrica de las imágenes, o sea, y a grandes
> rasfos, pasar de una imagen tomada por una cámara (deformación cónica) a
> que se ajuste a la realidad (proyección ortogonal) se resuelve teniendo
> presente (1) las características del sensor/cámara (cuál es su modelo
> "optico"), y, sobre todo, (2) reajustando las deformaciones del relieve [4].
>
> La imagen Bing en su mayor parte para España viene de imágenes de satélite
> de alta resolución (GeoEye / Quickbird) que son corregidas de manera
> automática (1) ajustando perfectamente la deformación del sensor pero con
> (2) un reajuste a la topografía que deriva de un  modelo digital del
> terreno muy grosero.
>
> Las imágenes del Plan Nacional de Ortofotografía Aérea del CNIG-IGN (PNOA)
> [5], sin embargo, derivan de un laborioso trabajo de rectificación de
> fotográficas tomadas desde un avión cuyo (1) ajuste del sensor es preciso
> (esto ya está superado para todos los sensores/cámaras digitales... hasta
> para los de vuestros móviles) y (2) 

Re: [Talk-es] highway=milestone

[Diego García]

Hola a todos; me estreno por esta lista tirando de móvil, no sé cómo saldrá.

Pienso que el sentido de una carretera (o camino, senda, autovía...)
debería estar determinado por el del vector que la dibuja, que a su vez
debe necesariamente coincidir con la denominación de la vía. Esto último
salva la ambigüedad que se podría dar en vías de doble sentido. Si en los
puntos kilómetros que la marcan se incluye información al respecto,
resultaría redundante.

Por otro lado, la inclusión en un mapa de dichos hitos, se hace para
señalar puntos de referencia (=orientación), no para determinar la
distancia, sea real o no, de la vía. Esto implica que la posición en el
mapa de un punto kilométrico debería ser lo más real posible en cuanto a su
posición, lo que descarta, en mi opinión, inclusiones masivas de datos
importados o resultado de extrapolaciones.

La designación como highway milestone, seguida de una etiqueta pk con el
valor en kilómetros, debería ser suficiente; aunque yo sería partidario,
además, de utilizar ref para indicar el nombre de la vía a la que pertenece
el hito.

Saludos,
 El 01/04/2015 13:42, Santiago Higuera shigu...@osgeo.org escribió:

 El mié, 01-04-2015 a las 13:19 +0200, Ignacio Turégano escribió:
  Comprendido, dejaremos el campo nombre para poner el nombre del PK
  como dices name=PK276 y utilizamos el campo pk=276 para el número.

 Para cálculos a grosso modo, la diferencia entre los números del PK
 puede servir como distancia. Es la distancia que se suele ver en los
 carteles de carreteras.

   Sigo sin ver bien el tag para indicar el sentido de la carretera si
  es creciente o decreciente.

 A lo mejor se puede añadir una etiqueta del tipo PkPrevious=algo que
 referencie el anterior PK, por su nodeId o algo así. En cualquier caso,
 el sentido se referiría al sentido creciente de los PK's en eje de la
 calzada. Según la calzada tenga uno o más sentidos de circulación, lo
 del sentido puede dar lugar a equívocos. No lo veo claro yo tampoco

  El PK será un nodo de la línea de la carretera a la que pertenece y
  contendrá el campo ref con el identificador de la carretera.
  (/offtopic tanto cuesta dejar a las carreteras con su nombre
  original?? se han parado a pensar cuanto cuesta renombrar una
  carretera? por ejemplo EX-xxx en una BA-xxx+CC-xxx el esfuerzo GIS
  para que sigan funcionando las herramientas con la misma carretera
 
 
  Mucho ojo con los PKs del CNIG hace tiempo les puse un email con un
  error en varios pks y me dijeron que ellos iban interpolando...tampoco
  queda muy clara su licencia para importar datos a OSM. No hay nada
  como un gps y la señal metálica ;) ahí no tienen nada que hacer
  diputaciones, cabildos y malos gestores de proyectos gis (véase
  carto*dad que no es ni cartografía navegable).
 
 
  ¿Creamos un PK de ejemplo fetén?


 
 
  El 1 de abril de 2015, 11:40, Santiago Higuera shigu...@osgeo.org
  escribió:
  El mié, 01-04-2015 a las 10:05 +0200, Ignacio Turégano
  escribió:
   talk-es@openstreetmap.org
  
   Antes de nada agradecer el esfuerzo y la velocidad en
  contestar, te
   contesto (y pregunto :) entre líneas
  
   El 31 de marzo de 2015, 20:34, Santiago Higuera
  shigu...@osgeo.org
   escribió:
   El mar, 31-03-2015 a las 17:04 +0200, Ignacio
  Turégano
   escribió:
Gracias por contestar tan rápido Santiago!
   
Vuelvo a la carga con más dudas que me surgen al
  leer tu
   respuesta.
   
Lo que me gustaría subir son los hitos
  kilométricos, por lo
   que el
utilizar el modo de PK+número no nos valdría si
  queremos
   utilizarlo
directamente en funciones del tipo Linear
  Referencing and
   Dynamic
Segmentation El modo PK+número del km estaría
  bien si solo
quisiéramos subir los hitos hito miriamétrico.
  
   Los Hitos kilométricos, en España, se designan por
  su número,
   por
   ejemplo el PK-15. Para referenciar un punto en una
  carretera
   se utiliza
   el PK anterior más próximo y la distancia en metros
  desde ese
   PK al
   punto en cuestión, en el sentido creciente de los
  PK, por
   ejemplo, el
   punto PK35+0090 es el que está 90 metros más allá
  del PK-35.
   Se ponen
   cuatro cifras y la distancia en metros, previendo la
   existencia de más
   de mil metros entre dos PK's consecutivos. El
  problema es que
   los PK's
   se