[Talk-mx] Importación de limites administrativos
Jorge Odenthal
jorge.odenthal en iacatas.org.mx
Mar Oct 13 07:22:07 UTC 2015
Hola Andrés:
la cita de Alex Barth está en hilo con el tema de a la importación en
general. Aqui va mi correo del 02.07. en el hilo sobre la importación del
MGM:
"Hola a todos:
estoy viendo la propuesta de importación del marco geoestadístico nacional
(MGN) y quiero comentar unas cosas:
1.plan de etiquetado: proponen nivel 5 para mpios. Actualmente, la mayoría
de los mpios tienen 6 lo que me parece bien. Hasta vale la pena discutir
nivel 8 para mpios (
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative) . El
nivel 5 es inaceptable para mpios por el simple hecho que no permite un
nivel de división intermedio entre edo y mpio como por ejemplo juntas
intermunicipales o zonas conurbanas.
2.. plan de importación: Importación de una sola ocasión " estamos pensando
que se pueden reemplazar por los límites del MGN para no invertir tiempo en
validar si son o no correctos los que ya existen". Eso me parece imposible
por lo siguiente. Muchas veces los limites siguen rasgos naturales como
rios, la costa o están vinculados a infraestructura como p.e. vías o
carreteras. Actualmente, hay muchos casos donde en OSM estás líneas están
compartidas y más exaxtas que el MGN. Una importación echa a perder esta
información. Hay que mencionar que el MGN no es la referencia oficial para
los límites.
3. ¿Qué se va a hacer en la costa? La línea costera y el MGN no coinciden.
4. la liga que respalda su propuesta para la sustitución completa está
rota Compatibilización
del Marco Geoestadístico Nacional a Límites Político-Administrativo
<http://infoteca.semarnat.gob.mx/website/MGN3_1.pdf%7C>
Saludos
Jorge"
El punto 1. se discutió en todos los foros y listas, pero al punto 2 y 3.
no hubo respuesta. aclaración, propuesta.
Saludos
Jorge
El 13 de octubre de 2015, 1:46, OpenStreetMap Mexico <
openstreetmapmx en gmail.com> escribió:
> Hola Jorge,
>
> El correo que citas no menciona en ningún momento que sea el consenso de
> la comunidad, de hecho no es un correo respecto a esta importación.
> Adicionalmente, las consecuencias que mencionas en el correo anterior son
> tu opinión personal. Nuevamente te insisto, no se estará eliminando ninguna
> información de OSM. El proceso de sustitución se definió así porque es la
> manera más eficiente de hacerlo en lugar de realizar una edición manual de
> cada límite para incluir la información correcta proveniente del INEGI. Si
> reemplazamos el dato de un límite con exactamente el mismo dato del límite
> pero mejorado y corregido no estamos incurriendo en ninguna edición
> inválida, por el contrario, estamos mejorando considerablemente la
> cobertura del mapa sin remover ningún dato, no podemos parar porque a tu
> parecer muy personal sea inválida la mejora y contribución que estamos
> haciendo al mapa.
>
> Saludos
>
> 2015-10-12 22:55 GMT-07:00 Jorge Odenthal <jorge.odenthal en iacatas.org.mx>:
>
>> Hola a todos:
>> me quedé todavía investigando en los correos y la página oficial de la
>> importación del marco geoestadístico de INEGI:
>> en un correo del 14.02.2015, Alex Barth escribe estos tres puntos:
>>
>> "Hola tod en s!
>>
>> (1) De acuerdo que no tiene sentido reemplazar datos que ya existen en
>> OSM con INEGI.
>>
>> (2) Acabo de hablar con Ruben aquí, hay más metadatos que hemos sacado
>> en el mapa, sacaremos una nueva capa. También pueden verlos en el shapefile
>> aquí
>> http://www3.inegi.org.mx/sistemas/productos/default.aspx?c=265&s=inegi&upc=702825278724&pf=prod&ef=&f=2&cl=0&tg=0&pg=0
>>
>> (3) El INEGI está interesado de detectar cambios en OSM para mejor
>> mantener sus propios datos. Un poco como lo hemos hecho en NY [1]. Creo que
>> aquí hay una bueno oportunidad para colaborar entre el INEGI y OSM con
>> ventajas para ambos partidos."
>>
>> Después, si no recuerdo mal ya no se tocaba el tema. Sin embargo, en la
>> página de la importación
>> http://wiki.openstreetmap.org/wiki/Mexico%27s_Administrative_Divisions_Import_Project se
>> dice en el capítulo: Data Merge Workflow
>> en el punto 5:
>> "Current admin_level=6 boundaries will be erased and replaced with the
>> same boundary data from MGN just with an addition of correct tagging scheme
>> since identifying and populating each and everyone of the current
>> admin_level=6 boundaries with the new tags would be time consuming and
>> error prone. It's validated that any boundary being erased and replaced
>> will be having the exact same valid boundary data from the MGN dataset.
>> This approach in no way harms users contributions since the data being
>> erased and replaced is of the exact same boundaries that there were already
>> in OSM as long as they were valid (please refer to the conflation
>> explanation below)."
>>
>> Pues yo traduzco replaced con reemplazado con las consecuencias que
>> mencioné en mi correo anterior. ¿Cuál es la razón para el cambio en el
>> procedimiento? ¿En qué momento y quién tomó esta decisión? cuando ya era
>> consenso que No será una importación completa.
>>
>> Saludos
>>
>> Jorge
>>
>> El 12 de octubre de 2015, 22:52, OpenStreetMap Mexico <
>> openstreetmapmx en 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 en 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 en openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-mx
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Talk-mx mailing list
>>> Talk-mx en 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
>>
>
>
> _______________________________________________
> Talk-mx mailing list
> Talk-mx en 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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.openstreetmap.org/pipermail/talk-mx/attachments/20151013/8a8b12e0/attachment-0001.html>
Más información sobre la lista de distribución Talk-mx