Hi, the team doing the current imports in mexico “killed” the boundary of the USA and Mexico near Rio Grande. They added “their” new boundaries and did not replace/split/change the original State boundaries of USA.
All missings in USA + the AL2 in Mexico and the USA are results of their Import.
Hi @wambacher, Welcome to subforum of México.
[sorry, I know little english; I used google translator]
A few minutes ago, I sent email to the list Talk-MX, and I gave notice of your post here in the forum.
In Talk-MX I read something on imports, so hopefully soon get in touch with you here in the forum.
Thank you for coming to this forum to present your concerns.
Greetings from Mexico.
Any relation from the boundaries that is missing will be reinstated once we finish the import, due to some glitches in our importing script some relation segments might be missing during the period of the import but we’ve backed up everything before proceeding with the import so that any data before the import is re-uploaded after the import.
Andrews, you and your guys are doing a good job, but the edits at the american boundary are critical!!! There are missing, duplicated and not connectetd Segments. Mainly you did not break the “new” segments and did not connect the american segments to it. This can not be fixed by “restoring saved segments”, that has to be done manually and as soon as possible.
If you are doing that in your own country, this may be acceptable (by your local community), but you killed about a dozend USA-Boundaries which must be fixed as soon as possible.
somebody told me you wrote at talk-mx something like. “no problem because you don’t see it on the map”.
That is totally wrong! You don’t see it on openstreetmap.org but the DATA is damaged. Every application using live data or downloading that data will get wrong data and will have big problems. Routing software like navigation software too.
OSM is a database - not a Map. Somehting you should have heard many times before.
We’re aware of the issue, any valid relation that was affected will be fixed. The data is not damaged since we backed it up before and we will reinstate whatever went wrong (even if that needs to be done manually).
Hi, i fixed all damaged boundaries of the USA. The mexican site should be fixed by the your guys.
WARNING: Don’t re-import “your” boundaries but fix them. Connect your AL4/Al6 and AL8 to the fixed outer boundaries of mexico and the Usa. If you are going to re-import those borders or keep on doing the same stuff at other areas, i’ll call DWG to revert your changes ASAP. That is not a joke.
EDIT: Same situation at least in Juárez(6). Old correct AL2 of Mexico and USA overlayed by new imported AL6 of Juárez.
Guadelupe, Ojinaga too. down the whole Rio Grande.
Our team validated all the relations in the MX-US border for admin_level=6, we don’t see any issues for that specific level for US counties in the border with Mexico anymore due to most of the fixes you made. (There’s an issue with Cochise county*, whose polygon is not closed but it was not caused by our import.)
I hope this post will help explain a little the method that we had chosen and some of the technique details that forced us to move from the initial proposed solution in some parts.
As always, this is a learning experiencing.
For the future we will have a better check mechanism, 4 persons where responsible for the relinking of the al4 al6 , with vary degree of experience. I will personally check what my colleagues had done and see if there are other parts that need cleaning.
There are still some things that will need to be done, to re-add the wikipedia tags to the relations where we had deleted
Checked all the mexico admin_level=4 boundaries that we had added, fixed where there was something not connected
the relation analyzer should update soon, the josm relation manager where showing a beautiful circle for the next provinces in mexico
Creo, al igual que wambacher que los limites son algo crítico, tanto los de nivel 2 para paises, como los de nivel 8 para las poblaciones.
No quiero parecer autoritario sino resaltar la importancia del asunto, pero a mi criterio, debiera ser, como comunidad, prioritario solucionarlos y asimilar los aprendizajes necesarios para tratar de evitar que la situacion se repita, tanto en un mejor QA de los imports, como en una mas rapida atencion/respuesta ante una advertencia de (posibles) problemas en un changeset que modifique elementos criticos.
Este tipo de ediciones debieran manejarse como algo transaccional, el mismo changeset modifica un limite, quizas mejorable pero coherente y sano, por otro actualizado mejor tambien sano, todo entero, en un mismo changeset. De esa forma los limites siempre se mantendrian idealmente sanos.
Tambien hubo algunos problemas con la linea costera en la zona del HOT por Patricia, pero eso creo que no fue por los imports sino por la cantidad de colaboradores editando simultaneamente en la zona.
You’re right in the sense that these matters should be taken with care, the problem was that as we we’re doing this import, hurricane Patricia hit and all of our team and resources (including servers) were put right away in the service of the Humanitarian OpenstreetMap team. At that moment we thought it was much more prioritary to help the HOT team with the resources we were dedicating to the boundaries import because the risk of this event being catastrophic. We don’t regret that decision but we didn’t plan for the unexpected, and we might have been distracted during the whole weekend with such activities, hence causing some mishaps during the boundaries import.
We’re on the track of fixing any issues that might have arised during the import and welcome any input based on clear evidence of an error in our side as the one expressed on this thread.
Si Andresuco, de las cosas que valoro de OSM es que cada grupo o individuo tenga la libertad para definir sus prioridades y trabajar en base a ellas, por eso agradezco tu explicacion, y de ninguna forma las cuestiono. Es entendible perfectamente que con la catastrofe natural las prioridades se hayan modificado.
Aunque no se refleje en el modelo de datos de OSM (porque es bien plano), hay elementos que son mas importantes que otros, como los limites o carreteras de mayor jerarquía, y es importante su continuidad para multiples consumidores del dato.
Por suerte lo inesperado no siempre es una catastre climática como la que sufrieron, pueden ser problemas personales de diversa indole, por eso es importante tratar de que los changesets sobre ciertos tipos de elementos cambien los mismos de un estado correcto a otro correcto.
Si fuera posible que el conjunto de cambios necesarios para una importación grande cumplan con esa propiedad de que cada cambio intermedio vaya dejando todo corecto, creo que eso le agrega mucho valor a una importacion, y el proceso total de la importacion puede demorarse mas tiempo que no afectaria demasiado.