[Talk-mx] Importación de limites administrativos

Mar Oct 13 05:51:17 UTC 2015

Hola Jorge,

Lo que es una apreciación personal es lo que tu consideras: que se perderá
información. Te repito No se perderá información. Lo que no me gusta es
eso, que digas cosas con base a tu apreciación personal, que son falsas.

Respondiendo a tu pregunta, cada que salga una versión nueva del INEGI NO
será necesario sustituir y borrar los cambios en el futuro porque los
cambios serán sobre lo que existió inicialmente mientras sea válido y los
cambios evidentemente podrán ser verificables contra la misma base, que es
la importación actual.

Respecto a la siguiente aseveración:

"Por supuesto se está perdiendo información en el momento cuando se crea
una capa exclusiva de boundarys, p.e. cuando una parte del boundary es un
río o una carretera o una barranca, etc., información por el momento
existente en OSM. No veo ninguna razón para perder esta vinculación entre
atributos físicos y administrativos. Al contrario, pienso que es un insumo
muy valioso para que el INEGI mejore su marco geoestadístico."

No se está perdiendo esa información, no sé a que te refieres respecto a
que la información que existe en OSM como ríos, carreteras o barrancas no
sé eliminarán, Te repito nuevamente que eso es una opinión tuya. El que se
separé un nodo que no forma parte de un límite administrativo de una
relación que sí lo es no implica que se pierda información alguna porque el
nodo sigue existiendo en la base de datos y no se borra.

Tu mismo te estás respondiendo, las relaciones evitan duplicidad de la
información. Tal como se menciona el el fragmento que citas.

Saludos cordiales,
Andrés

2015-10-12 21:39 GMT-07:00 Jorge Odenthal <jorge.odenthal at iacatas.org.mx>:

> Hola Andrés:
> me puedas por favor reenviar el comunicado y los anuncios.
> Que yo estoy desinformando a la comunidad es una apreciación personal
> tuya. Si no estás de acuerdo con mis observaciones, críticas o propuestas,
> es otra cosa. Y yo prefiero llevar la discusión a este nivel.
> Entiendo que no te gusta que a esta altura del proceso viene alguien para
> oponerse al método que han elaborado. Pero yo me opuse desde el inicio a su
> método y lo expresé por este medio. Y hasta ahora no entiendo por que sea
> necesario sustituir los límites existentes en OSM por el marco
> geoestadistico actual de INEGI. ¿Cuál es la necesidad? ¿Cada vez cuando
> sale una nueva versión de INEGI los van sustituir y borrar los cambios que
> los colaboradores mientras hicieron?
>
> Por supuesto se está perdiendo información en el momento cuando se crea
> una capa exclusiva de boundarys, p.e. cuando una parte del boundary es un
> río o una carretera o una barranca, etc., información por el momento
> existente en OSM. No veo ninguna razón para perder esta vinculación entre
> atributos físicos y administrativos. Al contrario, pienso que es un insumo
> muy valioso para que el INEGI mejore su marco geoestadístico.
>
> Las relaciones no son para mantener información separado sino más para
> evitar duplicidad de información. Un típico caso es cuando creas una
> relación de landuse = farmland y los límites del polígono tienen en tres
> lados barrier=hedge. En este caso conviertes el polígono en una relación,
> lo quebras en los puntos donde empieza y termina el seto (hedge) y asignas
> a esta línea barrier = hedge.
> En el caso de boundarys es igualmente un procedimiento legitimo. En la
> wikipedia boundary http://wiki.openstreetmap.org/wiki/Relation:boundary
> dice entre otras cosas:
> - Avoid to connect boundaries to physical features like woods or rivers.
> Sooner or later these features change in reality and get updated in OSM –
> but usually the shape of the boundary remains. An exception is if the
> boundary is legally defined to be the physical feature. (Evita conectar
> limites administrativos  con atributos como bosque o ríos. tarde o temprano
> estos atributos cambian y serán actualizados en OSM - pero normalmente los
> límites quedan. Una excepción se presenta en el caso que el límite es
> legalmente definido como el atributo físico (ríos, barrancas, ....)
> Y a esta excepción me refiero ya que es en México muy común.
>
> Saludos
>
> Jorge
>
> El 12 de octubre de 2015, 22:52, OpenStreetMap Mexico <
> openstreetmapmx at gmail.com> escribió:
>
>> Hola Jorge,
>>
>>
>>
>> Te aclaro que se comunicó ya en la lista y se realizó el anuncio a través
>> de todos los procesos formales con la lista de importaciones.
>>
>>
>>
>> Ninguna información se estaría perdiendo y te pido que por favor dejes de
>> des-informar a la comunidad como lo has hecho anteriormente por poner tu
>> propia interpretación de la información que es de nueva cuenta INCORRECTA.
>>
>>
>>
>> Te aclaro, no se estará perdiendo ninguna información porque los límites
>> administrativos no necesitan estar vinculados con la información de límites
>> naturales a nivel del dato, el hecho de que queden dos líneas idénticas una
>> sobre otra es válido mientras cada una forme parte de su propia relación o
>> tipo de vía, y es algo totalmente válido. El hecho de que la información se
>> mantenga separada es porque precisamente para eso son las relaciones. Para
>> mantener los datos de un límite geográfico, separados del límite natural.
>> Lo que sí es invalido a nivel dato es que los nodos formen parte al mismo
>> tiempo de dos vías (por ejemplo que formen parte de la relación de un
>> límite estatal  y a la vez de una calle o avenida).
>>
>>
>>
>> Saludos,
>>
>> Andrés
>>
>> 2015-10-12 19:24 GMT-07:00 Jorge Odenthal <jorge.odenthal at iacatas.org.mx>
>> :
>>
>>> Hola a todos:
>>>
>>> con sorpresa hoy me dí cuenta que según, el proceso de la importación de
>>> los límites administrativos fue aprobado por la comunidad. Si yo me
>>> recuerdo bien, en ningún foro o listas hubo un anuncio de este tipo. Aqui
>>> pido una aclaración de los organizadores de la importación.
>>>
>>> Desafortudanamente, unas dudas que yo había expresado desde el
>>> principio, no fueron resueltas. Una pregunta que yo habia expresado por
>>> este medio era como iban a manejar los casos donde lineas de los boundarys
>>> al mismo tienen otros atributos como ejemplo carreteras, ríos, setos, etc. (
>>> Way: Río Lerma (255992028)).  Nunca hubo una respuesta. Ahora en la
>>> página de la importación no hay mención alguna. Pero, según la página, se
>>> van a sustituir todos limites actuales por la última versión de INEGI. Para
>>> mi es un grave error. En el caso de la importación completa esta
>>> vinculación de la información se perderá ya que quedarían dos lineas
>>> identicas pero con información separada. Yo me imagino que INEGI no cuenta
>>> con esta información que puede ser bastante útil para la mejora del marco
>>> geoestadístico.
>>> Mi propuesta de la importación será la siguiente:
>>> 1. Respetar la información de OSM e importar nada más los municipios
>>> donde todavía no hay límites.
>>> 2. Poner a discusión los polígonos donde hay discrepancia entre OSM y
>>> INEGI (puede ser que OSM corresponde a los limites reales y no INEGI)
>>>
>>> Mientras este punto no se resuelve, NO estoy de acuerdo con el
>>> procedimiento como está planeada en la página de importación.
>>>
>>> Saludos
>>>
>>> Jorge
>>>
>>> --
>>> Jorge (Georg) Odenthal
>>> Investigaciones Aplicadas en Ciencias Ambientales y Sociales, IACATAS
>>> A.C.
>>>
>>> Ukurio s/n
>>> San Jerónimo Purenchécuaro
>>> 58430 Quiroga, Mich.
>>>
>>> Skype: jorge.odenthal
>>>
>>> http://www.iacatas.org.mx/mapas/index.html
>>>
>>> http://iacatas.org.mx/odenthal
>>>
>>> _______________________________________________
>>> Talk-mx mailing list
>>> Talk-mx at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-mx
>>>
>>>
>>
>> _______________________________________________
>> Talk-mx mailing list
>> Talk-mx at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-mx
>>
>>
>
>
> --
> Jorge (Georg) Odenthal
> Investigaciones Aplicadas en Ciencias Ambientales y Sociales, IACATAS A.C.
>
> Ukurio s/n
> San Jerónimo Purenchécuaro
> 58430 Quiroga, Mich.
>
> Skype: jorge.odenthal
>
> http://www.iacatas.org.mx/mapas/index.html
>
> http://iacatas.org.mx/odenthal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-mx/attachments/20151012/fcee3153/attachment.html>