stevesong / kml2ofds Goto Github PK

The current algorithm assumes that LineStrings are more or less sequential and heading in the same direction. I am not sure how to parse cases where two LineStrings, that are part of the same MultiGeometry object, both start line middle and work their way outward. For the time being will have to mention it as a caveat until a workaround is found.

Currently the code assigns a node to any span endpoint that does not already have one. In some cases, where two spans terminate close to each other, it may be that the the map is intended to be contiguous at this point. We could look for spans that terminate very close to each other and join those spans into a single span.

Alternatively, further on in the code, we could look for two "Auto generated nodes" that are close together and reduce it to a single node connecting the two spans.

For some detailed KML maps, users may wish to exclude certain features from the export. Add the option to specify features to ignore in the .ini file.

The current code doesn't cope well with polylines that intersect each other. Short term strategy is to test for this and generate an error, suggesting that the KML should be adjusted to remove intersections.

Namibia's Grid fibre network https://thegridonline.network/?page_id=770 contains Placemark and LineString elements with IDs e.g.

Will probably have to use findall rather than iter. e.g.

# Parse your KML file
with open('your_file.kml', 'rb') as kml_file:
    root = parser.parse(kml_file).getroot()

# Define the namespace
namespace = "{http://www.opengis.net/kml/2.2}"

# Find all Placemark elements regardless of their ID
placemarks = root.findall(".//" + namespace + "Placemark")

# Iterate over found Placemarks
for placemark in placemarks:
    # Do whatever you need with each Placemark
    # For example, print its ID
    placemark_id = placemark.get("id")

In OFDS, a network fork should be a node at which three spans terminate. When network mappers draw a network fork in KML, they may choose to draw the fork by drawing a new line that begins close to an existing polyline. The current code does not have the capability to detect and resolve forks that are created this way.

This could be an Auto generated missing node. (note that "Auto generated missing nodes" are created to terminate any polyline that doesn't end in a node, in order to be compliant with OFDS which requires all spans to be terminated by a node at either end)

or a named node

There is a need for functionality that would detect nodes that are within a certain proximity to a polyline but not either end of the polyline. In these instances, we should break the polyline at the nearest vertex of the polyline and use the node as the terminating point.