pasos para definir un área administrativa

Hola.

Según la wiki para definir un área administrativa, no solo se debe crear la relación que la define, sino que también hay que agregar los labels a las vías que la definen. Sacado de la wiki:

For a place which is also an administrative area:

create a closed way around the perimeter of the area using one or more ways.
Tagged these ways with boundary=administrative and with appropriate admin_level=*.
Add these ways to a Relation:multipolygon)
Add a boundary=administrative and appropriate admin_level=* to the relation
Set the role of each way as 'outer' unless there is an enclave, in which case set it to inner.
Optionally add a node at the centre of the administrative area and give it a role of "admin_centre". 

¿Esto es siempre así? De no hacerlo así, ¿estaría mal? o ¿es redundante?

Pregunto porque leyendo acerca de las etiquetas “is_in:*”, entre otras cosas dice que dentro de áreas administrativas bien definidas, éstas son redundantes. Por esto es que me surgió la duda respecto de agregar las etiquetas a las vías, mas allá de las relaciones.

Las vías heredan la información de las relaciones que contienen, por lo que no deben tener nada que ya esté en la relación (por ejemplo, los tags “boundary=administrative”, “admin_level=*”, etc.). En caso contrario lo único que vas a notar es que el render va a dibujar el límite con un trazo más grueso que lo normal donde la vía está definida con el tag “boundary=administrative”.

Si bien los tags “is_in:*” son redundantes, aparentemente habría algunas aplicaciones que dependen de OSM que los están usando, por lo que esa información debe ir en la relación (no en la vía).

En cuanto al admin_centre: tenés que seleccionar el “place” que corresponda a la cabecera de partido o departamento y agregarle la relación del partido o departamento poniéndole el rol “admin_centre”.

Supongamos un área xx que es un éjido municipal dentro del departamento de añelo, que es solo una parte de añelo, no todo el departamento. En los tags “is_in:**” no me figura una opción “añelo”; como he visto que en buenos aires, por ejemplo, un barrio de Moreno, en los tags aparece una opción predefinida “is_in:municipality” y luego en el contendio podés poner “Moreno” como opción predefinida también. ¿como logro esto en mi caso?

Eso no está estandarizado. Como los departamentos no son municipalidades en varias provincias, quizá se podría usar is_in:region. Otra posibilidad sería is_in:county (de condado, que es un escalón por debajo de los estados de los EEUU). Este último método tiene la ventaja que, al usar el sistema de los EEUU, sería más compatible con aplicaciones GPS.

Por supuesto, habría que ver qué es lo que opinan otros con respecto a este tema.

En nuestra wiki está bien explicado y como se deben armar
Desconozco la división politica de Neuquen pero calculo q los departamentos asumirian el rol de los partidos en BA y eso tb está contemplado en nuestra wiki

Bien. Gracias. De todas maneras, para aclarar, en Neuquén, en un mismo departamento puede haber mas de un municipio. De hecho en el que vivo hay 4 municipios o mas.

Dudas desde la lectura de la wiki arg:

  • ¿siempre ponemos en la relacion: type=boundary en lugar de type=multiplygon?

  • he visto que cuando le damos el atributo “place” a un nodo, este abarca cierto ‘radio’ por así decirlo. A veces mas grande de lo que en realidad es, por eso creo que es mejor rodear con un multipoligono y delimitar de esta forma el área, como pueden ser los barrios, por ejemplo. La pregunta es: si coloco un nodo “place” dentro de esta un barrio delimitado como dijimos, ¿se ve este place limitado también por el límite definido con el multipoligono/relación?

  • Deberías usar admin_level=7 en el caso de las municipalidades, como lo dice la wiki, en este caso, por ejemplo: http://www.openstreetmap.org/browse/relation/2598332. ¿es así?

La información brindada por la Wiki no está muy clara. Lo que yo entendí, es que el admin_level=7 debe abarcar el municipio completo, es decir que incluye el área rural en caso de existir. El admin_level=8 es para el área urbana exclusivamente. El admin_level=9 es para los barrios en los que se puede subdividir esa área urbana.

El caso es diferente, ya que en la provincia de Buenos Aires el partido es lo mismo que el municipio, cosa que ocurre en muy pocas provincias. Entonces no se puede usar in_municipality:Añelo refieriéndose al departamento ya que éste tiene dos municipios: San Patricio del Chañar (de primera categoría), Añelo (de segunda categoría); y una comisión de fomento: Aguada San Roque.

Yo había completado en http://wiki.openstreetmap.org/wiki/Admin_level el status de la Argentina. Aclara que departamento y partido son lo mismo, agrega un nivel entre departamento y municipio para ciertas provincias, y que el nivel 7 de municipios no corresponde para Provincia de Buenos Aires, Mendoza, La Rioja y San Juan, ya que en ellos municipio=departamento/partido.

Para mi está bastante claro esto. Y entendí lo mismo que vos.

Lo entendí perfectamente. Es casi lo mismo que lo anterior… ¿o no?

Pregunto otra vez:

El “se ve” depende del render. En el caso del render web, yo estoy poniendo en las ciudades que estoy mapeando los tag place y name tanto en el nodo como en la relacion que tiene los limites. La etiqueta la muestra en el lugar donde esta el nodo.

Originalmente lo definí como type=multipolygon, lo podes ver en la imagén, pero alguién lo edito. Aunque ambos son correctos, antiguamente no existian los multipolygons

Los tag place, no tiene radio, es simplmente el más cercano. El tag place no está delimitado por ninguna relación son independientes

¿Te referís al tipo de relacion? Es cierto que da error de verificación de rol si lo dejas como multipolygons y no lo hace cuando lo dejas como boundary.

Bien, gracias. He visto que suelen generar una falsa información los tag place a veces, de acuerdo a la distribución que tengan en el mapa.

El osm inspector da una señal de alarma respecto de las relaciones tipo “boundary”…

http://tools.geofabrik.de/osmi/?view=multipolygon&lon=-68.09050&lat=-38.96541&zoom=13&overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes

¿Porque es esto? ¿Es mejor definir la relación tipo “multipolygon”?

Se de la diferencia que existe cuando se hace la verficiación de rol, respecto del centro administrativo.

Evidentemente als actualizaciones tanto de definiciones como SWs no están todas al día y por eso se producen esos errores