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

Ander Pijoan ander.pijoan en deusto.es
Vie Jun 15 13:04:43 BST 2012


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.

El 15 de junio de 2012 13:48, Jorge Sanz Sanfructuoso
<sanchi2 en gmail.com>escribió:

> La logica que siempre se a seguido o por lo menos en general para
> decir que no se usen relaciones es que es mas sencillo de editar, y
> algo menos aunque tambien se a dicho que es menos carga para los
> servidores.
>
> Lo de mas sencillo de editar como ya han comentado por aqui no es así.
> Ponte a editar en un sitio que se junten varios trazados y me lo
> cuentas. Proceso que sigo yo y creo que al final es el mas facil.
> Coger a ver que poligono sale si no es el que quieres agregarle un
> nodo y apartarlo. Ir al siguiente si pasa lo mismo otra vez hasta que
> llegas al que quieres. Cuando llegas ya lo modificas y borrar los
> nodos que has creado que sobran, si hay algún nodo mio suelto raro ya
> sabeis porque puede ser. jejeje.
>
> Lo de la carga a los servidores creo que si que da mas carga eso no lo
> discuto.
>
> Se da mucho por hecho por aqui que ningún tipo de relación maxima va a
> ser aceptada por la lista de imports, entonces me pregunto ¿porque se
> acepto la de Girona?. Si no me equivoco se paso por la lista de
> imports. Creo que habría que reducir el numero de relaciones y después
> ver que dicen.
>
> El día 15 de junio de 2012 13:13, Ander Pijoan
> <ander.pijoan en deusto.es> escribió:
> > Creo que no nos estamos entendiendo.
> >
> > Se puede resumir todo en una pregunta: ¿Qué problema habría si cat2osm
> > sacase los datos tal y como están en Alemania o Francia?
> >
> > El 15 de junio de 2012 13:06, Jaime Crespo <jynus en jynus.com> escribió:
> >
> >> El día 15 de junio de 2012 12:48, Ander Pijoan
> >> <ander.pijoan en deusto.es> escribió:
> >> > No pero no me refiero a eso Jynus.
> >>
> >> > Me refiero a que utilizar relations para optimizar no me parece que
> sea
> >> > correcto
> >> > (ni que optimice). Las relations son para agrupar elementos con un
> mismo
> >> > significado o relacionados, valga la redundancia, y eso lo estabamos
> >> > haciendo bien.
> >>
> >> Pues tienes una idea equivocadísima de las relaciones. ¿Juntamos en
> >> una relación todos los amenity=bar de una ciudad? ¿campus de Deusto?
> >> Obviamente no, usamos tags.
> >>
> >> Y qué obsesionados estáis todos con optimizar. ¿Acaso alguien ha
> >> hablado realmente con los sysadmins -y no con los de imports, que sus
> >> criterios son otros, de mantenimiento de los datos- sobre cuánto
> >> afecta eso a sus servidores?
> >>
> >> ----------------------
> >>
> >> Respecto a la complejidad:
> >>
> >> No quiero usuarios vagos. Precisamente el hecho de que cosas complejas
> >> de por sí son complejas evita todos los vandalismos en OSM (si no
> >> sabes editar una frontera entre dos países, no lo hagas).
> >>
> >> Ahora bien, todo lo que sea sencillo, que sea lo más sencillo posible.
> >> La forma de los edificios se puede cambiar sin problemas por cualquier
> >> usuario (siguen siendo ways), y es probablemente más fácil con
> >> relaciones, porque no tiene que "acertar" cuál es el polígono
> >> correcto.
> >>
> >> OSM es un proyecto colaborativo, por lo que hay que anteponer la
> >> edición fácil a la "optimización" de los servidores. (Si tu software
> >> no es capaz de entender relaciones no es problema del modelo de datos
> >> de osm, sino de que tendrás que hacer una conversión antes, como hace
> >> mapnik). Y si los editores no lo hacen fácil, se modifican los
> >> editores para hacerlo fácil, no la forma de editar de la gente.
> >>
> >> Dicho esto, yo aquí hace un tiempo propuse subir masas (como ways, sin
> >> agujeros) a pelo y portales (como nodos) - mira qué fáciles de editar.
> >> Y ya estaría satisfecho. Eso sí, los de imports te dirán que no de
> >> nuevo (lo último de la lista es que deberían borrarse todos los
> >> edificios de OSM porque no tienen valor).
> >>
> >> --
> >> Jaime Crespo
> >>
> >> _______________________________________________
> >> Talk-es mailing list
> >> Talk-es en openstreetmap.org
> >> http://lists.openstreetmap.org/listinfo/talk-es
> >
> >
> >
> >
> > --
> > Ander Pijoan Lamas
> > Ingeniero Técnico en Informática de Gestión
> > Universidad de Deusto
> >
> > Contacto:
> > Email: ander.pijoan en deusto.es
> > Móvil: +34 664471228
> >
> >
> > _______________________________________________
> > Talk-es mailing list
> > Talk-es en openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-es
> >
>
>
>
> --
> Jorge Sanz Sanfructuoso - Sanchi
> Blog http://blog.jorgesanzs.com/
>
> _______________________________________________
> Talk-es mailing list
> Talk-es en openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-es
>



-- 
Ander Pijoan Lamas
Ingeniero Técnico en Informática de Gestión
Universidad de Deusto

Contacto:
Email: ander.pijoan en deusto.es
Móvil: +34 664471228
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.openstreetmap.org/pipermail/talk-es/attachments/20120615/ec4ad9fd/attachment-0001.html>


Más información sobre la lista de distribución Talk-es