Finally, the project for importing the municipalities limits is finished. It took longer than expected considering some of the issues that arose during the project. First I would like to thank all the members of the team, and also to the volunteers who helped the team when doubts and issues arose.

Importing official data to OSM seems like a simple task at first, and it is up to certain extent,but when the amount of data is not that big, however when we talk about all the municipal limits of the whole country like in this case, problems might arise.

First problem, data availability. Before we started with this project (previous to 2014), the geographic data from the Mexican Government weren’t open. there was the possibility to get them for academic or personal use but using them in a project like OpenStreetMap required overcoming a series of legal gray areas which no team would be willing to deal unless they had the resources to tackle it. The best example of this case is Google, the team from Google Maps has used Mexico’s official geographic data (that means the databases from the INEGI) throughout the years, nevertheless before this data was declared open data by the Mexican Government, you needed a series of legal and licensing agreements that required analysis by a legal team, hence it was a considerable amount of expenses just to create a project of cooperation with the government, that’s the kind of deal only a big corporation like google could afford to fund so, as good as the information from INEGI might be , no individual or team from the OSM community would have the means to afford the expenses required in a licensing deal just to import data to OpenStreetMap, in fact that was one of the reasons we initially thought about creating a NGO to push the geographic open data agenda within the MExican Government.

However, and in a kind of surprising way, the government took the decision to release a lot of their data as open data, including the geographical data. The way in which this happened and the factors that allowed this to happen would need another post, but if you’re interested a bit of the history woul could watch the conference given by [] from the INEGI when he was invited to give a conference in the State of the Map LatAM in 2014 in Chile.

Once the data was declared open data by the government, it ceased to exist the need of an entity whose agenda was to push for the opening of the government’s geographic data. It was then that we better focused on the following objective which was taking advantage of the richness of the INEGI data in OSM and it’s up to certain point a perfect example of why the governments should release their data as open data, if not for the fact that the government’s initiative to open their data came to fruition, our efforts would have been spent on lobbying and political activism instead of starting to work with the data and use them for the benefit of the citizens (which at the end is one of the objectives of the work the INEGI does), besides the fact that there was no certainty that all that lobbying work would really push our agenda until its final objective of opening the data, so it’s a really fortunate fact that this had happened in an organic way within that institution itself and within the mexican government. Governments and institutions who manage geographic data in other countries could take note of this.

Second issue, data conversion and conservation. Uploading data within an import is not that simple, you must follow a series of procedures in order to preserve the previous information, even regardless of previous data validity, in order to avoid destroying valuable data previously contributed by osm users, it’s really complicated to validate automatically which information is valid and which isn’t’ for a whole country unless there’s a very clear and specific reason such as data going against the OSM tagging rules which is the only guide to determine what data should be kept, however that’s not enough and you should make a backup previous to the import.

For starters, the data for boundaries doesn’t come ready to be uploaded to OSM out of the shapefile, it’s on a INEGI specific projection, and it’s not topologically ready to be converted from shapefile format to osm format, it needs to be reprojected, transformed, and properly split at the common boundaries, this is an important step to avoid way duplicity and we found out it will be a real challenge for more granular boundaries like the colonias boundaries.

Just an example, once converted to OSM compatible format, the limits file had more than 1,700,000 elements, which can’t just be uploaded in a single changeset, it was necessary to split this huge file into several changesets in order for the OSM API to allow the data to be updated and also to validate errors in a state by state basis, which meant an enormous amount of time spent doing manual work, such as the verification of the admin_centre and the separation of non boundary data merged to boundary ways, since by replacing this limits with the addition of the backed up data we could be incurring in uploading errors from the restored data which would end up being a disservice for the osm map. The detection of such errors was done with the help of some scripts, but the evaluation of whether it was an error or not ended up most of the time being judged by the team, based on the editing guidelines of OSM, which took a considerable amount of time compared to a 100% script based validation and was of course exposed to human error.

In the case of Mexico’s municipal limits, we’re talking about 2,457 limits for which there were some previously limits present in selected states, where it was clear that they were imported from the INEGI but never documented and hence were invalid, in this case we replaced the limit with the updated INEGI data including the data identifier from the source at INEGI in order to facilitate future updates of these limits whenever the source updates them and also the other way around, for the INEGI to retrieve this data from OSM to identify where it should update its mapping efforts on the field based on what the OSM community is updating.

Third problem, idiosyncrasies, since before we started with the import, we knew from reading of the experiences of other previous imports, that some people is never happy with the imports, either because they don’t share they same objectives of the importing team or because they have their own interpretation of the philosophy of openstreetmap on which they consider themselves owners and guardians for the data they contributed, and assume that no one else should touch or modify their contributed data. This notion that whomever trying to improve OSM through a big scale import is destroying or damaging OMS is well known within the community since the times of the TIGER import in the United States, but the reality is that OSM wouldn’t be what it is today in part thanks to the importing efforts or it may be, only that it would take longer to improve without such efforts. Errors might be made, but if that’s the cost for improving the map at a reasonable speed then I think that’s a reasonable tradeoff as long as the errors are fixed.

Opinionated and polarizing views will always take place in open source communities, some folks will be satanized just because being part of a corporation or for having their own agenda, but in reality everyone has their own agenda, the point is whether those agendas contribute to the improvement of the project.

In order to keep this import current and to help out the INEGI to update the cartography of municipal limits, we set out to list every municipal boundary in Mexico’s OSM Wiki (Thanks Irk_Ley !) , this way the INEGI, and actually anyone, will be able to track which boundaries are being modified according to the local legislation which is possible for those users that have a legal backup to modify the boundaries from the ones that INEGI set.

Finally I would like to thank all from the import team noting it wasn’t only people from Telenav but we also received a great deal of technical support from the the HOT OSM team , local OSM mappers from Mexico and Puerto Rico and Europe. I don’t mention names because they’re all already listed in the import wiki ;)

Finalmente el proyecto de la importación de los límites municipales de México ha terminado. Tomó más de lo esperado en especial considerando algunos de los problemas que surgieron a lo largo del proyecto. En primera me gustaría agradecer a los miembros del equipo, y también a los voluntarios que nos ayudaron cuando surgieron dudas y problemas.

Importar datos oficiales a OSM parece una tarea sencilla y hasta cierto punto lo es cuando la cantidad de datos es pequeña, sin embargo cuando se habla de los límites municipales de un país como en este caso específico, los problemas surgen.

Primer problema, disponibilidad de los datos. Antes de comenzar con este proyecto (previo a 2014) los datos geográficos del gobierno mexicano no eran abiertos, existía la posibilidad de obtenerlos para proyectos académicos o personales pero el hecho de usarlos en un proyecto como OSM involucraba superar una serie de lagunas legales con las que ningún equipo estaría dispuesto a lidiar, a menos que tuviera los recursos para hacerlo. El mejor ejemplo de este caso es Google, el equipo de Google Maps ha usado durante años la información geográfica oficial del gobierno mexicano (Es decir las bases de datos del INEGI), sin embargo, antes de que esta información fuera declarada como datos abiertos por el gobierno mexicano, se necesitaba una serie de convenios legales de licenciamiento que requerían la revisión de abogados y por lo tanto de un gasto considerable en crear un proyecto de cooperación con dicha entidad. Ese es el tipo de convenios que sólo una corporación tan grande como Google puede darse el lujo de financiar así que por muy buena que fuera la información proveniente del INEGI, ningún individuo u organización de la comunidad OSM tendría los medios para afrontar los gastos en la gestión de un proyecto de licenciamiento tan sólo para importar datos a OpenStreetMap, de hecho esa fue una de las razones por las que inicialmente queríamos crear una Organización no Gubernamental para empujar la agenda de datos geográficos abiertos en el gobierno mexicano.

Sin embargo y de manera un poco inesperada, el gobierno tomó la decisión de abrir muchos datos, incluidos los geográficos, la manera en que ha sucedido esto y los factores que lo permitieron es materia para otro post pero si les interesa un poco de la historia, pueden ver la conferencia que dió [Nombre] del INEGI cuando fue invitado a participar en la conferencia State of the Map LatAM 2014 en Chile.

Una vez que los datos fueron declarados datos abiertos por el gobierno, dejó de existir la necesidad de crear un grupo de presión que empujara dicha agenda. Fue entonces cuando nos enfocamos en el siguiente objetivo que era aprovechar la riqueza de los datos del INEGI en OSM, y es hasta cierto punto un ejemplo perfecto de por qué los gobiernos deberían de liberar sus datos como datos abiertos, de no ser por la iniciativa del gobierno mexicano y del INEGI de liberar estos datos, nuestros esfuerzos se habrían centrado en activismo político y lobbying en lugar de poner las manos a la obra y usar los datos para el provecho de los ciudadanos (que a final de cuentas es uno de los objetivos del trabajo que hace el INEGI), además de que no existía la certeza de que todo ese trabajo realmente empujaría nuestra agenda hasta su objetivo final de abrir los datos, así que es un hecho muy afortunado que esto haya sucedido de manera orgánica dentro de esa institución y dentro del gobierno mexicano. Los gobiernos e instituciones a cargo de datos geográficos en otros países podrían tomar nota de esto.

Segundo problema, conservación de los datos, Subir datos en una importación no es tan sencillo, es necesario seguir una serie de procedimientos con el fin de preservar la información previa incluso a pesar de que no haya garantía de que esa información sea válida, esto con el fin de no destruir información previa que sea valiosa, es muy complicado determinar automáticamente cuál información es válida y cuál no para todo un país a menos que haya una razón muy específica, como que vaya en contra de los lineamientos de etiquetado de OSM y es la única guía para determinar qué conservar y qué no. Sin embargo se debe realizar un respaldo de la información previamente a la labor de importación.

Para empezar, los datos de los límites no vienen listos para ser subidos a OSM recién salidos del shapefile, están en una proyección específica del INEGI, y están topológicamente preparados para convertirse de formato shapefile a formato OSM, se necesitan reproyectar, transformar y dividir entre los límites en común, este es un paso importante para evitar duplicidad de ways y nos dimos cuenta que ese será un gran reto para la importación de límites más granulares como los límites de las colonias por ejemplo.

Tan solo un ejemplo, una vez convertidos al formato de datos de OSM el archivo de los límites contenía más de 1,700,000 elementos, lo cual no pueden ser subidos en un solo changeset, se requirió dividir este total en varios changesets a fin de que la API de OSM permitiera que se subieran tantos datos y también para validar errores estado por estado lo cual significó una enorme cantidad de trabajo manual como la verificación de los admin_centre y de la separación de datos fusionados con los límites previos ya que al sustituirlos podríamos volver a incluir una gran cantidad de errores en la información restaurada. La detección de dichos errores fue realizada con ayuda de scripts pero la evaluación de si es un error o no quedaba muchas veces a juicio del equipo basado en los lineamientos de edición de OSM lo cual tomaba evidentemente más tiempo que un script y estaba sujeta a errores humanos.

En el caso de los límites municipales de México estamos hablando de 2457 municipios para los cuales a pesar de existir previamente para algunos estados, donde era evidente que la información se importó del INEGI pero nunca estuvieron documentadas y por lo tanto eran inválidos, en este caso solo se reemplazó el límite con los datos del INEGI incluyendo la clave del dato proveniente del INEGI a fin de dar seguimiento a futuro en los casos en que el INEGI actualice un límite y también para que el INEGI sepa qué límites está actualizando la comunidad.

Tercer problema, idiosincrasia, desde antes de comenzar con la importación sabíamos por la experiencia al leer sobre importaciones previas que la gente nunca está contenta con las importaciones, a veces por que no comparten los mismos objetivos que el equipo de importación o porque tienen su propia interpretación de la filosofía de openstreetmap en la que se consideran dueños de los datos que contribuyen y asumen que nadie más debe tocarlos o modificarlos. Esta noción de que quien sea que trate de mejorar OSM a través de una importación a gran escala está destruyendo o haciendo daño a OSM ya es bien conocida en la comunidad desde los tiempos de la importación de los datos de TIGER en Estados Unidos, pero la realidad es que OSM no sería lo que es hoy sin muchos esfuerzos de importaciones, o tal vez tomaría demasiado tiempo en mejorar si no existieran dichos esfuerzos. Se podrían cometer errores pero si ese es el costo que hay que pagar por mejorar el mapa a una velocidad razonable creo que es un intercambio razonable siempre y cuando se corrijan los errores.

Opiniones polarizantes siempre habrá en las comunidades de código abierto, algunas personas serán satanizadas sólo por pertenecer a una corporación privada o serán culpados de tener su propia agenda, pero en realidad cada quien tiene su propia agenda, el punto es si esas agendas contribuyen a la mejora del proyecto.

Con el fin de mantener esta importación relevante y actualizada, y ayudar tanto a la comunidad de OSM como al INEGI a actualizar la cartografía de los límites municipales, nos dimos a la tarea de enlistar cada límite municipal en el wiki de OSM de México (Gracias Irk_Ley !), de esta manera el INEGI, y de hecho cualquier usuario, podrá monitorear qué límites están siendo modificados de acuerdo con una legislación local, lo cual es posible ya que algunos usuarios tienen dicho respaldo legal para modificar los límites que especificó el INEGI.

Finalmente me gustaría agradecer a todo el equipo de importación, notando que no sólo fue gente de Telenav, también recibimos un gran apoyo técnico de parte el equipo de HOT OSM así como de la comunidad de maperos de México, Puerto Rico y Europa. No menciono nombres porque ya todos están en la lista del equipo en el wiki ;)

El pasado fin de participé en State of the Map LatAm 2015 presentando el seguimiento a lo que mostramos en NY el pasado mes de Julio respecto a los datos del INEGI con los que queremos mejorar OpenStreetMap.

Fue muy interesante observar lo que están haciendo otros miembros de la comunidad OSM en Latinoamérica, algunos de los principales puntos que me gustaría remarcar y que pude observar durante esta conferencia fueron los siguientes.

1. México no va tan mal en lo que respecta a datos, tenemos ya los datos liberados, estamos analizando la calidad y en un trabajo en conjunto con el gobierno mexicano y con el INEGI vamos con paso lento pero seguro en lo que respecta a los proyectos de importación de datos a OSM.

2. La comunidad en México no tiene tantos proyectos en concreto como la comunidad en Latinoamérica, lo que quiero decir con esto es que vi un montón de proyectos montados sobre OSM en países como Chile, Brasil, Paraguay y Argentina, y son el tipo de proyectos que no vemos en México. Hay herramientas como el Changeset Analyser que presentó Wille Marcel de Brazil , hay iniciativas como la que presentó Jose Luis Moraes para que se use OSM en de Correios Brasileiros y que de hecho ha sido bien recibida por los carteros quienes incluso han aprendido a usar el ID Editor o por ejemplo el uso de OSM por la UOCT en Chile para verificar el tráfico en Santiago y quienes mostraron como migraron de GoogleMaps a OSM para mejorar el desempeño del mapa desplegado en su sitio y disminuir sus costos de operación.

3. El uso de OSM en proyectos relacionados con el medio ambiente también estuvo muy presente en proyectos como el del estudio de las cuencas urbanas en Chile, que presentó Carolina Ojeda o el proyecto de Mapazonia y de Mapas Livres de Vitor George.

En resumen fue un fin de semana muy productivo y de gran importancia para avanzar en la integración de la comunidad a nivel regional que también ha sido uno de los problemas anteriores en la comunidad latinoamericana de OSM, ya que aunque las comunidades sean pequeñas en cada país o aunque estén dispersas, muchas veces las temáticas o los problemas que se tratan de abordar son los mismos; accesibilidad, ecología, transporte público, rutas para bicicletas, calidad y verificación de los datos así como el fomento del uso de OSM en el gobierno, en la academia y por parte de la sociedad civil.

Regresé de este evento con una gran entusiasmo por poder lograr fomentar en la comunidad OSM de México proyectos como los que vi de parte de nuestros hermanos en toda Latinoamérica y creo que la manera de hacerlo es difundiendo con mayor frecuencia no sólo los proyectos que se presentaron en SOTM LatAm 2015 sino la filosofía de OSM y de la apertura de datos desde el gobierno, parece una tarea difícil pero si un país como México, (con todos los retos que tiene en lo que respecta a transparencia y corrupción) logró abrir sus datos para que sean usados en una plataforma como OSM entonces significa que no es imposible lograrlo en otros países de la región con culturas y retos similares. Fue un gusto haber participado en este evento y mis felicitaciones al equipo de OSM Chile, Telenav y Mapbox por organizarlo.

Last weekend, Miriam and me presented some of our findings at NYC State of the Map US 2015. We showed the work we have done so far by analyzing some of the datasets released by the INEGI (Mexican Institute of Statistics and Geography).

The importance of this presentation was to kickoff the discussion for the use of government geographic data released in Mexico under the new terms of use “Libre Uso MX” as well as giving the audience an idea of the quality of the data that could potentially enrich the OSM map of Mexico.

You can find the presentation slides here and the video of all the presentations including ours at the SOTM US website.

![Mexico presentes en SOTM US 2015] (http://40.media.tumblr.com/49bf5cda7fbb74174b8d2e8f92cc3769/tumblr_npr9syQX201u6nudio1_540.jpg)

If you are interested in supporting the analysis and extraction of INEGI data to improve the map of Mexico in OSM please send me a message or follow any of the Mexico’s OpenStreetMap community channels at @OpenStreetMapMX , OSM Mexico in FB and osm.org.mx.