add support for parsing subsections of OSM files based on name, e.g., "New South Wales", or "Sydney", instead of rect bounding box only #56
Comments
MarkRaadsen
added
documentation
|
Based on OSM tagging. Propose we go for: boundary and then - in simplest form - go for administrative boundary unless explicitly indicated via settings. Then take first match that is found, see https://wiki.openstreetmap.org/wiki/Key:boundary?uselang=en |
… work as before. Not yet implemented support for name based boundary though. todo, not done
…o be able to pre-process and extract boundary from OSM relations. NOT DONE YET - create polygon from OsmBoundary on networkBaseHandler based on settings and use that instead of the one on settings. Then implement osmRelation handling in pre-processing further
…ne --> preprocessing of network now needs to be done twice to make this possible with OSM4J: first implement the two phases (enum created but not yet enforced) stage 1: do nothing by register the name and not create the polygon. In stage 2 extract the ways with outer roles and in complete() create the overall polygon from the line strings --> then put it on the network data there and it can be used in main processing (also to be implemented because it is not yet used then remove the initialise bit from the basehandler I think that is still there but is not needed. then feed this through all the way
|
NOTE: needs a bit more sophistication --> bounding area can be defined separately for zoning and services parsing --> yet currently the code to extract this is scattered through preProcessingHandler and network reader. We do not want to copy this across to the Zoning reader and handlers. SOLUTION: Create an OsmBoundingBoundaryBuilder which will contain the code for the various pre-processing steps now in the networkhandler as well as the functionality to then construct a new OsmBoundary. This code can then be reused in network/zoning/services readers. This is the next thing to do <-- REFACTORING, then testing |
…ne (instead of using settings). However, this is whole support is also need for zoning reader. See comment on issue on how to avoid duplicate code and make this a more general and contained piece of code. NOT DONE. after refactoring, replace use of setting boundingboundary with the one on the data objects passes around.
…work and zoning reader) + refactored into boundary manager to avoid duplicate code. Base implementation done. Needs thorough testing though. + check if this works with intermodal (not looked at yet)
|
write tests with various bounding boundaries for network only, pt only, network and pt both and intermodal to see if it is working, also test various configs (with boundary type other than administrative and different admin_level values. |
…g box is directly specified (not by name)
…ssing functionality based on unit test. NOT DONE
|
It is likely that using a name for the bounding area is more likely to be used than a rectangular bounding box. As such tracking the spanning square bounding box and flagging warnings based on this spanning bb is no longer a good default way of doing things. So, we discontinue using this method as the default and instead replace it by using the bounding boundary instead. Only if we have no bounding boundary we revert to the spanning bounding box |
… bugs/missing functionality based on unit test. NOT DONE
… bugs/missing functionality based on unit test. NOT DONE (See issue comment)
|
Testing reveals inefficient construction of OSM ways + currently we make to many nodes/ways available even if they fall entirely outside the bounding area specified. Debug this to fix up. Another general improvement to all of this would be to do the preprocessing of the bounding area before doing anything with preregistering of OSM nodes, this would allow for a more flexible approach where we only preregister nodes within the bounding area, then register OSM ways that have at least one node in the area (fully), and then register all nodes that are part of those ways. This would simplify checking and would also reduce the number of error message regarding missing nodes |
…tter as per comment above. NOT DONE
|
Further improve: the new approach as per above can cause an OSMway to have NO nodes within bounding area, but due to another OSMway that is intersecting with it to be partially within the bounding area still have some nodes available even though it should NOT be considered --> so if the first node of a link is not available and another is chosen it should be checked if that node falls within the bounding area, if not then we should discard the OSM way quietly....example OSMway 4269134 for melbourne named bounding box test --> then continue refactoring to reduce checks/logging due to this improved approach --> then do the same for zoning UPDATE: first part dealt with using secondary pre-registration to avoid this problemand not preregister such OSM ways, see comment below on how to best continue. pre-registration of nodes now sorted it seems |
|
Partly implemented above. Likely best to instead keep a register (of ids) of OSMWays that were found eligible during preprocessing. Only when they are found eligible we should bother parsing them in the network main processing --> then ease the logging/warning regarding bounding boxes that are now triggered during node collection etc. This approach should be more elegant --> then apply same approach to zoning |
…gible Osmways explicitly now and id some refactoring as well.
|
ease the logging/warning regarding bounding boxes that are now triggered during node collection and when creating link because this should now never be needed anymore and we can remove all that somewhat ugly code |
…OT DONE -> continue with correct support for zoning/intermodal in same way as we do preprocessing passes for network, then debug based on logging to see if it is working correctly on Melbourne
… reader now implemented in zoning reader. Tests run but partly fail. NEeds detailed debugging and refinements before completion
…ns) + made a start with logging based on whether OSM entities are within bounding area. Basics work for this refactor but tests still need fixing for Melbourne. so first task not yet done
|
…g new approach to boundary. Test results replaced after verification (not tested with services active)
…boundary manager to track boundary nodes (no longer in general pool of tracked nodes). Network converter still needs refactoring to support spatial eligibility based on how it is done in zoning though, but prep work for it has been done.
…e preprocessing handler to deal with just identifying the bounding boundary. Used by both zoning and network reader, refactoring of preprocessing (non-boundary related_ in network and zoning since no longer needs to deal with bounding boundary stages, so cleaner. Still needs further testing.
…ns eligible spatially when they are also eligible for zoning parsing, i.e., PT infrastructure compatible (excluding routes therefore).
…nd named (increased performance for intermodal reader), updated tests
add support for parsing subsections of OSM files based on name, e.g., "New South Wales", or "Sydney", instead of rect bounding box only
The text was updated successfully, but these errors were encountered: