[Talk-co] Límites de los Municipios y otros unidades administrativos de Colombia

Oscar.Ramos en cafedecolombia.com Oscar.Ramos en cafedecolombia.com
Vie Ene 15 12:46:47 GMT 2010


ok. Se nombra la relacion... p.ej.    Vereda "Alfa" conformada por los 
tramos A,B,C. ; pero el tramo B junto con X,Y,Z esta conformando la vereda 
"Beta". 

Cuando usted nombra la vereda "Alfa", y quiere nombrar despues la "Beta", 
el tramo B que es que estan compartiendo, se va a denominar "Alfa" o 
"Beta".... no me guarda el nombre de ambos....

Como usted cuadraria las etiquetas de estos casos???




De:
Germán Márquez Mejía <manchito en gmail.com>
Para:
OpenStreetMap Colombia <talk-co en openstreetmap.org>
Fecha:
15/01/2010 02:24 a.m.
Asunto:
Re: [Talk-co] Límites de los Municipios y otros unidades administrativos 
de Colombia
Enviado por:
talk-co-bounces en openstreetmap.org



Los segmentos de frontera no reciben nombre, precisamente porque pueden 
delimitar múltiples áreas simultáneamente. En su lugar, el nombre de la 
vereda 
se le pone a la relación. Por lo que he visto, los nombres de ambos lados 
de 
la frontera pueden o no aparecer a lo largo del tramo. En todo caso, el 
render 
no debería ser un criterio para determinar si la frontera está bien o mal 
nombrada.

El Jue 14 Ene 2010 23:33:21 Oscar.Ramos en cafedecolombia.com escribió:
> Ya he estado trabajando algo al respecto con unas veredas....
> Pero por ejemplo un segmento "a" pertenece a su vez a la vereda "Alfa" y
> "Beta"
> El problema es que el segmento solamente recibe un nombre  (Alfa o Beta) 
y
> no recibe los dos. Asi, cuando vemos en el Render, aparece solo el 
nombre
> de una de las dos veredas.
> ¿Como podemos solucionar esto?
>
> Cordialmente,
> OSCAR RAMOS OVIEDO
> Comite de Cafeteros del Tolima
>
>
>
> De:
> Germán Márquez Mejía <manchito en gmail.com>
> Para:
> OpenStreetMap Colombia <talk-co en openstreetmap.org>
> Fecha:
> 14/01/2010 05:13 p.m.
> Asunto:
> Re: [Talk-co] Límites de los Municipios y otros unidades administrativos
> de Colombia
> Enviado por:
> talk-co-bounces en openstreetmap.org
>
>
>
> Bueno, pues lo dicho: hablé con los de OSM-Alemania. Fue muy productiva 
la
>
> reunión,
> resolví dudas y me levanté unos cuantos tips cartográficos. Mandan 
saludes
> a
> OSM-Colombia.
>
> Respecto a boundary vs. multipolygon:
>
> Optaron por multipolygon por varias razones.
> 1. Simplicidad: si se puede hacer lo mismo con una relación que ya
> existía,
> pues es mejor que añadir otra (boundary).
> 2. boundary es redundante en el sentido de que dentro de una relación
> boundary, se debe poner también un tag
> boundary=administrative|political|...
> 3. Para enclaves y territorios de ultramar es tan sencillo como inner o
> outer,
> sin necesidad de tags adicionales como enclave exclave.
> 4. Se pueden especificar unidades administrativas sin necesidad de que
> todo el
> contorno esté completo.
> 5. Las unidades administrativas son áreas más que fronteras y 
multipolygon
>
> encaja mejor en ese concepto.
>
> Todavía hay muchas zonas con la relación boundary en lugar de
> multipolygon,
> pero están en proceso de cambio. Para más info.
> 
http://wiki.openstreetmap.org/wiki/Talk:Relation:boundary#Use_type.3Dmultip

>olygon_instead
>
>
> De esta manera, cada segmento de frontera queda así:
>
> boundary=administrative (si es de varios tipos se separa con ";")
> admin_level=4 (cuando coincide con otros niveles se pone el más alto de
> ellos
> -o sea el menor número)
>
> Nótese que left/right:town|state... están obsoletas, o sea que si hay
> segmentos que tengan esos tags, hay que quitárselos.
>
> Luego, si se tienen los segmentos a, b, y c que conforman la unidad
> territorial X, la relación quedaría así:
>
> name=X
> type=multipolygon
> boundary=administrative (un único tipo por relación)
> admin_level=4 (un único nivel por relación)
>
> Y como miembros: a, b y c con el rol outer (excepto en los casos de
> divisiones
> especiales -enclaves, ultramar, etc.- donde se utiliza inner según se
> necesite). Si aún no se tiene el contorno completo, pues se ponen los 
que
> están y, cuando se tenga el que falta, se agrega a la relación.
>
> Así, un mismo segmento de frontera puede pertenecer a varias relaciones,
> sin
> importar el nivel o tipo de unidad territorial.
>
> Otra cosa: me aconsejaron que, cuando la frontera sea un río u otro tipo
> de
> vía, es una buena práctica ponerla como OTRA vía superpuesta para así
> evitar
> combinar tags (v.gr. name: ¿es el nombre del río o de la frontera?) o
> segmentarlos innecesariamente.
>
> Espero opiniones y debate. :)
>
> Saludos,
>
> El Jue 14 Ene 2010 16:34:22 Germán Márquez Mejía escribió:
> > Pues está entre
> > http://wiki.openstreetmap.org/wiki/Relations/Proposed/Boundaries y
> > http://wiki.openstreetmap.org/wiki/Relation:multipolygon.
> >
> > Pero a pesar de que la relación boundary está como propuesta, me 
atrevo
>
> a
>
> > decir, por lo que acabo de ver en el mapa, que lo que dice la wiki 
sobre
> > Alemania y Holanda no es del todo cierto. La mayoría de fronteras 
están
>
> con
>
> > boundary y no con multipolygon y los resultados de las búsquedas se
>
> atienen
>
> > a esa división. Personalmente, me gusta más la idea de boundary.
> >
> > Sería chévere, si no se ha hecho ya, empezar una discusión para 
ponernos
>
> de
>
> > acuerdo en si boundary o multipolygon, explorando las ventajas y
> > desventajas de cada opción antes de arrancar a utilizarlas. Igual voy 
a
> > echarle un ojo a la discusión que se dio aquí en Alemania, o incluso
> > pegarme la pasada por la reunión mensual del grupo de trabajo de OSM
>
> Berlín
>
> > (que justo es esta noche), y preguntar.
> >
> > Lo que sí haré seguro es borrar los left y right que había puesto,
>
> porque
>
> > ya están en desuso.
> >
> > Saludos,

-- 
In a world without walls or fences, who needs windows and gates?

_______________________________________________
Talk-co mailing list
Talk-co en openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-co


------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.openstreetmap.org/pipermail/talk-co/attachments/20100115/29973d28/attachment.html>


More information about the Talk-co mailing list