[Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...

[Antonio Navarro]

Hola,

Aunque soy un novato total y muchas de las implicaciones quizá no las
entienda, creo que una solución podría ser dejarlo como está, para que
genere las relaciones (que parece que 'formalmente' es más correcto en
muchos casos) y añadir una opción (vía parámetro o vía fichero de
configuración) para que lo haga todo con vías superpuestas. De esta forma
no perderíamos funcionalidad y quedaría a criterio de cada uno generar la
información como prefiera. Claro que no tengo ni idea de cómo sería de
costoso técnicamente hacer esto :-)

En mi opinión después de estar viendo los ficheros generados para Talavera
y para Cazalegas, sinceramente no veo claro tanta relación. Lo de las vías
superpuestas no es que sea la panacea, pero me parece más simple.

Un saludo,

-- 
Antonio Navarro
----------------------------
mailto:antonio en hunos.net
mailto:antonio.navarro.es en gmail.com
mailto:antonio.navarro en hispalinux.es
----------------------------


El 15 de junio de 2012 18:23, Javier Sánchez <javiersanp en gmail.com>escribió:

> El día 15 de junio de 2012 13:04, Ander Pijoan
> <ander.pijoan en deusto.es> escribió:
> > Yo no digo eliminar las relaciones de cuajo del resultado allí donde
> hagan
> > falta (edificios con agujeros, lineas de autobus con sus paradas,
> carreteras
> > muy largas, trazados de ferrocarril...). Para eso son las relaciones.
> >
> > Lo que digo que creo que no hay que hacer y que no aporta ninguna
> ventaja es
> > utilizar relaciones para reutilizar ways. ¿En qué parte de la wiki de
> OSM se
> > indica que tenga que hacerse eso así?
> >
> > Lo de Girona no se lo que dirían en su día y, también hay que decirlo,
> tal y
> > como están esas, construcciones están correctas, pero ¿qué beneficia el
> > hacerlo así? ¿Puestos a pedir por qué yo no podría hacer que una
> población
> > sea una relation grande, cuyos members son otras relations que son sus
> > manzanas con role inner, esas manzanas a su vez compuestas de otras
> > relations que son las parcelas...
> >
> > El esquema lo permite, pero llega un momento en el que no tiene sentido
> y no
> > mejora nada.
> >
> > Lo normal en OSM
> >
> http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/05/MarbleRelationParsing4.png
> >
> > Lo que se propuso para cat2osm en un principio pero que ya no lo veo
> lógico.
> >
> http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/05/MarbleRelationParsing31.png
> >
> > Esta reutilización de geometrías para evitar bordes superpuestos vuelvo a
> > repetir que no mejora nada. Para todo lo demás, las relaciones siguen
> siendo
> > totalmente necesarias.
>
>
> Hay que buscar un término medio. Emplear vías superpuestas en unos
> casos y relaciones en otros según nos interese, y fusionar vías
> adyacentes con los mismos usos en los casos en que está claro como
> rústico.
>
> Ahora bien, veo dos formas de hacerlo.
>
> A) Reescribir todo el código para que genere vías superpuestas excepto
> relaciones en algunos casos.
>
> B) Dejar el código más o menos como está, generando relaciones para
> todo y pasar un proceso posterior que simplifique relaciones y
> sustituya por vías superpuestas en algunos casos.
>
> Supongo que B da menos trabajo pero tendrá más coste en tiempo de proceso.
>
> Javier.
>
> _______________________________________________
> Talk-es mailing list
> Talk-es en openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-es
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.openstreetmap.org/pipermail/talk-es/attachments/20120615/72babb77/attachment.html>