retaining network attributes

[lenkahas]

label:enhancement

This package is super useful. I've been using it to simplify networks for a large-scale routing exercise.
The only thing I am missing in this package is the retention of some of the network attributes that need to be used later. For example, calculating the time it takes to drive the route, one needs the lengths of the roads and the speed limits. Lengths are calculated from the resulting lines, but the speed limits are an additional attribute coming from OSM.

I have been going around this by extracting the information by intersecting the original network with the neat one, using some buffer distance from the new network features to get the average speed limit in surrounding roads, but I don't find this very artful.
I can just about understand some of the code in this package, and I guess this might be possible by retaining the average value of the additional attribute from the original network for each FaceArtifact and then assigning that value back at some point?

Happy to help where I can!

[martinfleis]

It is a bit trickier than it sounds but rather conceptually than technically. When there is a new LineString as a replacement of multiple old ones, we could simply apply some aggfunc on the attributes, that is not that complex to do. The issue is that if you take, for example, a cluster of multiple artifacts that is replaces by a Voronoi skeleton, it is much harder to match original and new geometries. At the same time, you want to retain directionality of attributes, so when there is an intersection of two dual carriageways, new lines going north-south are aggregation of north-south original lines only and the same along west-east. And what shall happen with slip lanes connecting those is pretty much undefined. It gets awfully complicated super quickly, that is why we aborted this idea originally. But if you have a specific idea how to conceptually design this, it might be feasible to implement.

[lenkahas]

I can see the complexity of it.
Perhaps this would be an interesting task for a project in next year's Google Summer of Code?

[martinfleis]

I don't think neatnet would qualify for GSoC. It is not linked to NumFOCUS in any way, which is our typical route.

[lenkahas]

aw, apologies for my ignorance.
Should I close this for now, then?
Just checked the closed logs, is this related to #6 and #261 to some extent?

[martinfleis]

Keep it open, it is relevant. It is related to other two, but those are dealing with geometries where there is no aggregation needed, so 1:1 relationship either on existing to existing geometries or existing to changed. Not to new geometries.

[gsagostini]

Just to weigh in, could a temporary solution be to pass on attributes very generously? So in your example of the two dual carriageways intersecting, an imperfect but reasonable solution would be to just give both connecting slip lanes attributes from all four lanes. Then if needed users could choose to post-process the attributes (after getting the results from neatify) based on, say, continuity of an attribute they have (e.g. street name) or someone can develop a more geometric approach based on intersections and distances (e.g. in the particular || and = intersection, the slip lane should receive the attributes of the two lines it is not intersecting i.e. is parallel to).

This would make it easier for folks who need attributes to work with neatnet, and then they have the opportunity to clean up the attributes. Currently I have no shot at cleaning up attributes because none are assigned sometimes. Maybe one could simply pass on original indices for now, not to mislead users into thinking the attributes are correct. So basically you would just be saying "this edge was created from the geometries of these ones".

[martinfleis]

Maybe one could simply pass on original indices for now, not to mislead users into thinking the attributes are correct. So basically you would just be saying "this edge was created from the geometries of these ones".

I like this idea. We would need to be more careful about keeping the original index around but that should be feasible.