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 <manch...@gmail.com> Para: OpenStreetMap Colombia <talk-co@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-boun...@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.3Dmultipolygon_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, > -- Mancho _______________________________________________ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
_______________________________________________ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
