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

[Javier Sánchez]

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.