add support for parsing subsections of OSM files based on name, e.g., "New South Wales", or "Sydney", instead of rect bounding box only

[MarkRaadsen]

add support for parsing subsections of OSM files based on name, e.g., "New South Wales", or "Sydney", instead of rect bounding box only

[MarkRaadsen]

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

[MarkRaadsen]

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

[MarkRaadsen]

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.

[MarkRaadsen]

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

[MarkRaadsen]

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

[MarkRaadsen]

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

[MarkRaadsen]

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

[MarkRaadsen]

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

[MarkRaadsen]

• [x] fix up existing tests (except Melbourne) so that they pass
• [x] fix up Melbourne tests so that they pass + debug to see if the zoning portion of the code holds up
• [ ] Melbourne test now with network + zoning + services to see if the services portion of the code holds up new implementation and compare, only after that looks good replace because XML only is not easy to compare
• [ ] add stats on how many OSMways and OSMnodes and OSMrelations have been identified out of total in file like in network
• [ ] add stats on how many OSMways and OSMnodes and OSMrelations have been identified out of total in file like in zoning
• [x] should remove redundant checks for near bounding polygon logging in zoning as well
• [ ] see if we do not lose some platforms etc., as it is slightly less clear what is pt related. Aim is to identify and register all ways/-nodes/relations in pre-processing so in main processing we can assume all are present without exception (and if not then this is a big error rather than a potential one, so logging can be more to the point)
• [x] Refactor OSM network data parsing by splitting out to spatially eligible from (pre)Registration like in zoning, this is a better approach. Store this info in a separate data class. Possibly the OSMBoundary one. Also zoning stages can be reduced (six) and pre processing stages should ideally be done in their own preprocessing handler
• [ ] check if this is all working well with PLANitGTFS (found a bug in processing stops + we should support a bounding area so we can refactor the near bounding box stuff as we did for OSM to make it more precise