Filtrar por fichero geojson #79
Conversation
catatom2osm/app.py
Outdated
| if self.zone: | ||
| """Filter feat by zone label if needed.""" | ||
| return len(self.zone) == 0 or self.building.get_label(feat) in self.zone | ||
| if self.options.geojson: |
There was a problem hiding this comment.
Este método se usa para filtrar edificios, las partes, piscinas y direcciones. Si ponemos este filtro, el polígono split tendría que estar dibujado de forma quirúrgica para meter dentro exactamente lo que queremos y que no se cuele una parte de un edificio y se quede huerfana, sin su edificio o una dirección lo mismo.
La idea sería filtrar el fichero de zonificación. De esa forma no hay que ser tan preciso dibujando el polígono. Da igual si se dibuja un poco más grande y se pasa por el medio de otras zonas, sólo se van a incluir las que están contenidas (contains) no las que toque (overlaps).
Como se va a generar un archivo geojson necesario para el gestor de tareas y ese archivo debe contener sólo las zonas que nos interesan mi idea era eliminar físicamente las zonas. Si las capas de zonificación (urban y rustic) contienen sólo las zonas del split. Aquí no hace falta filtrar y resto del programa queda igual casi.
Si puedes, hay que aplicar el código que puse en #78 (la condición de filtro estaba mal, la he negado) a un distrito de Madrid. Para evaluar si tarda mucho tiempo en eliminar las zonas.
Por que otra forma de hacerlo sería obtener una lista de las zonas buenas, ponerla en options.zone y procesar como si se hubiera usado la opción -o. En ese caso, al crear el zoning.geojson habría que hacerlo sobre una selección de las zonas. Necesitamos evaluar cual de las dos formas es más rápida para Madrid.
There was a problem hiding this comment.
He hecho una prueba rápida eliminando en Madrid todas las zonas y tarda cero coma.
Otro motivo por el que interesa eliminar es que process_zoning tarda un montón, con sólo un distrito tardará menos.
El problema con esta manera de hacerlo es en get_buildings, las llamadas a building.get_labels necesitan que las capas de zonificación estén completas, mientras que buildings.append que estén filtradas. Quizá es necesario separar cosas.
There was a problem hiding this comment.
Ok, aunque sigo sin tener claro dónde llamarlo. La definición del split lo pones en get_building, y quito el contains del zone_query, hasta ahí bien. ¿Dónde aplico el corte, en el get_zoning?
There was a problem hiding this comment.
Perdona pero no tengo costumbre de manejar PR y me lio. La sugerencia que puse es para poner fuera de get_buildings, no dentro. De hecho la reemplaza. El corte de zonificación lo hace self.zone_split. La llamada a zone_split tiene que ser posterior a los get_labels y anterior a los append. Creo que falta poner en self.options.zone una lista con las etiquetas de las zonas filtradas y el programa pasará a comportarse igual que si hubiéramos usado -o
There was a problem hiding this comment.
Mira a ver el último commit, he metido los cambios sugeridos, excepto el verdadero filtrado, el contenido de la función zone_split. Confírmame si es así lo que quieres, luego ya faltaría procesar todas las posibles feature y realizar el corte, según dices, esa misma función cortaría self.building no?
There was a problem hiding this comment.
Bueno, un detalle menor, por gramática inglesa y de programación, la función debería llamarse split_zoning, no al revés como he puesto 😇
|
Un detalle importante, y es que estoy mergeando esta PR contra tu development, no contra tu master. Aviso por si acaso |
|
Si eso es muy importante, mantener la master lo más limpia posible. De
hecho lo suyo sería hacer una rama por issue, luego fusionar en development.
El vie, 31 dic 2021 a las 9:57, Hugoren Martinako ***@***.***>)
escribió:
… Un detalle importante, y es que estoy mergeando esta PR contra tu
development, no contra tu master. Aviso por si acaso
—
Reply to this email directly, view it on GitHub
<#79 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMIBRMOFFGQOGWSHBQC3Z3UTV46ZANCNFSM5LAMTIHA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Lo cambiamos
El vie., 31 dic. 2021 10:03, Hugoren Martinako ***@***.***>
escribió:
… ***@***.**** commented on this pull request.
------------------------------
In catatom2osm/app.py
<#79 (comment)>:
> def zone_query(self, feat, kwargs):
- """Filter feat by zone label if needed."""
- return len(self.zone) == 0 or self.building.get_label(feat) in self.zone
+ if self.zone:
+ """Filter feat by zone label if needed."""
+ return len(self.zone) == 0 or self.building.get_label(feat) in self.zone
+ if self.options.geojson:
Bueno, un detalle menor, por gramática inglesa y de programación, la
función debería llamarse split_zoning, no al revés como he puesto 😇
—
Reply to this email directly, view it on GitHub
<#79 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMIBRKJN2VAIQKFNTNRPC3UTV5WPANCNFSM5LAMTIHA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.Message ID:
***@***.***>
|
A través del parámetro
-go--geojsonpuedes especificar la ruta a un fichero con un geojson.Faltarían las pruebas de si no es válido y demás casos que fijo me he dejado, échale un ojo y me cuentas.