Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [sumo-user] Issues updating large (and old) network with new OSM data
1. I don't have a good solution for this. Presumably, most of the id changes happen because users split osm ways to incorporate more/differentiated attributes.  If if you had perfect mapping between which old ids correspond to which list of new ids, it still wouldn't be easy to figure how a patch should be applied (i.e. should a change in lane number be applied to all pieces or only some of them)? And maybe the patch isn't needed anymore because the newer data resolved the problem you fixed manually before.

You could use netdiff option --write-shapes to visuallize the modified elements in the newer network (independent of their ids) and redo them if still applicable.
I'm not sure what you mean by "made the diff really cluttered". Presumably, the diff is computed between the old and the edited network and so isn't affected by any id changes which the new network brings. (only it's applicability should be impacted if you try to use it with a new network).


2. One possible reason is a diff which leaves things to be computed by netconvert (i.e. if a diff changes edges but doesn't specify connections, then they must be re-guessed). In this case, a newer version of netconvert could do things differently form an older version. But apart from that it may well be a big in netdiff or even netconvert. Please provide a minimal problem example for replication!

regards,
Jakob

Am Fr., 24. Jan. 2025 um 11:47 Uhr schrieb Schweppenhäuser, Moritz via sumo-user <sumo-user@xxxxxxxxxxx>:

Hey everyone,

I recently tried myself on updating a fairly large network, which was generated using OSM data and netconvert. Furthermore, it went quite a bit of manual adjustments.

In my wishful thinking I hoped to be able to take current OSM data, use “netdiff“ to generate a diff between the original  netconvert output and the manually adjusted network, and then apply the diff to the new network generated using current OSM data.

Unfortunately, some issues occurred during this process.

  1. First off, from my impression, a lot of OSM-ways had their id changed in the past years, which made the diff really cluttered and also not really applicable.
  2. Additionally, I’ve encountered some issues where I would generate a diff between two networks, apply the diff on the original network and have a resulting network that is different from the changed one (see image).
    Which basically means that netdiff is not able to capture all differences between A and B.

 

Are there any hints you can give me on how to best tackle these problems? Especially regarding the first point.

 

Thanks in advance

Moritz Schweppenhäuser

 

_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user

Back to the top