Hmm... okay, so it looks like each <polygon> Block is actually a sub neighbourhood under the <g> Ward. BUt that would mean I'd need to export out 2 SVGs, i guess. Then, if I do need to determine which buildings in the individual polygon buildings list (in the 2nd detailed SVG) belong to which <polygon> Block , I'd check if their centroids (actually, any corner point would do..) lie within the Block polygon. Since they are chunked-listed together, I need to only check against last matching Block polygon until the candidate building centroid breaks out of it, then scan all Blocks again under that given <g> Ward group of Block polygons to update the current ward polygon region
For the road map analysis, I guess the Block-only SVG has to be used then, moving forward.
But I did wish Watabou would include sub-group neighborhood information within the <g> ward as that was avialable in the previous version and now this version lost it and now I'd have to refer to 2 svgs (and do point in polygon checks to get back the group the buildings of polygons...bleh).
___________
Regarding how i analyse roads, i'm still doing a WIP tool that actually intends to do a lot more though (note: older version SVG):
https://github.com/Glidias/yuka/blob/kralchester/src/towngen/SVGCityReader.js
Currently, the code is long and messy and I haven't organised everything yet but is mainly testing out various features only so i'm just highlighting parts of the svg for trace . I'm actually using this to further expand the city out into a multi-storey-themed city, by scanning the exported SVG and using it as a procedural base for expansion/sub-generation. THat is why I differentitate different road hierachies for the purpose fo having certain road types appear at higher altitudes compared to others. But this would also mean in order to access lower level roads at junctions, certain buildings at the corners of those junctions ( or merged buildings with other Neighbourng bsp tree cells from sibling nodes ) would need to be converted to stair-ramp-landings, ( to form a basis for like zig zagging flight of stairs) to provide some form of pedestrian walking access to lower levels of the city. I'm working on this part atm.
ANyway, there are 3 road hierachies. The highway (thick road spaces in orange), the ward streets (roads around wards spaces in purple), and the inner neighborhood lanes ( narrow grooves within <g> ward due to BSP tree lanes in turquoise). THe highway ramps down just outside the City wall exits (note lighter shade of orange), otherwise, without a CIty Wall, the intention si to have them at the last-outlying wards. I managed to calculate Ward distance costs to City Wall or from Ward region to Ward region, via some navmesh generation + graph navigation routines.
I decided to use node/JS because of some libraries already available in JS, and didn't take the Haxe route here though.
Basically, to analyse the roads and seperate them out, here's how I do it in summary:
Anyway, here's how i sort of reverse engineer the SVG to get more "information" from it
https://github.com/Glidias/yuka/blob/a94b35f5085b17d39cc13f4f39b94cfc53b28af5/src/towngen/SVGCityReader.js#L1246
For ward level roads (main highways and roads adjacient to Wards..) You simply form a CDT (constrained delaunay triangulation) of the entire set of Wards' convex hulls by defining the Ward's convex hulls as edges of holes (onto the entire square map canvas (also defined as an exteriour edge at first)) from the entire set of vertices of all Ward's convex hulls. I use cdt2d library for this. The vertices that belong to a Ward's convex hull, is given an integer ID that matches the ward's integer ID.
https://github.com/Glidias/yuka/blob/a94b35f5085b17d39cc13f4f39b94cfc53b28af5/src/towngen/SVGCityReader.js#L1522
After applying CDT, I filter off the polygons that contain vertices at the 4 corners of the map canvas and this leaves behind the road parts (more or less..).s. Then, i form a navmesh out of the CDT set of triangules using Yuka library's navmesh to form a navmesh out of those roads. After that, i scan each navmesh's regions' connecting portal edges to see if the left vertex and right vertex of the portal edge is belonging to 2 different Ward, if it is, then that region will be given an assositated ID assosiating that region with those adjacient/incident Wards. This is done for all portal edges of every navmesh region. (I also do a perpendicular width check along the portal edge to get the opposite edge across, then find perpendicular distance to measure the width of the road and determine if it's a valid road region or not). After that, i combine the set of IDs into an array, sort them, then join them to a consistently ordered string concatenated with "_" to give each raod section a unique ID. Road sections that are assosiated to to the exact similar set of adjacient Wards, will end up receiving the same ID due to the sorting. (So yes, T junctions or crossroad junctions will have different IDs compared to the main road that only lies between 2 wards, etc. and can therefore be potentially named differently).