Re: [sumo-user] dropping undesired neigbor lane guesses

[Richter Gerald <Gerald.Richter@xxxxxxxxx>]

Oh well, and then you of course need the option
--guess-symmetric=true/false
which says that if you have an edge within the allowed included ids,
you also add the symmetric association from its neighbor back to the 
included edge.
(Otherwise you get 1-way opposite lane overtaking allowed for asymmetric 
associations)

regards,
Gerald

On 25.09.20 13:30, Richter Gerald wrote:
> Hi Jakob,
>
> thanks for the instructions and asking!
> When you mention "more" options I am afraid to contribute to the number
> that already are there ;)
>
> But yes.
> For *netconvert* and the specific case, I think it were good to be able
> to specify at least files with lists of edge ids to
> --include-edgeIds or --exclude-edgeIds
> in the guessing process.
>
> If includes are given: guess only those edges and their neighbors
> If excludes are given: all but those
> If both: includes <set difference> excludes
>
> In *netedit* it were great to be able to clear out/remove the neigh tag
> within a selection list,
> also reminding in the log output if there are asymmetric neighbor
> associations left (L1 -> L2 but *not* L2 -> L1.)
>
> best,
> Gerald
>
> On 25.09.20 12:58, Jakob Erdmann wrote:
>> Hi Gerald,
>> Is there an systematic problem with the way --opposites.guess works
>> that could be fixed (or refined with more options) for everybody?
>> The recommended way of patching a network is (as always) with netconvert.
>> You can either:
>> 1)
>>     a) convert the net to plain-xml
>>     b) manipulate the .edg.xml to remove some neigh elements
>>     c) rebuild the network
>>
>> or 2) patch the network
>> https://github.com/eclipse/sumo/tree/master/tests/netconvert/import/XML/diff/remove_opposite
>>
>> regards,
>> Jakob
>>
>>
>> Am Fr., 25. Sept. 2020 um 08:09 Uhr schrieb Richter Gerald
>> <Gerald.Richter@xxxxxxxxx <mailto:Gerald.Richter@xxxxxxxxx>>:
>>
>>      Hi,
>>
>>
>>      having generated a net N with as many neighboring lane guesses as
>>      "netconvert-ly" possible
>>
>>      from an original intact net A
>>
>>      I suspects these neighbor rules to be problematic or unnecessary
>>      in some stretches of the network.
>>
>>
>>      So there is the need for bulk removal of *some* of the neighboring
>>      info.
>>
>>
>>      The plan I've come up & started with so far is:
>>
>>       1. scan the net N along a route definition of edge id's
>>       2. by loading this net with sumolib
>>       3. hopping along the route via outgoing edges
>>       4. retrieving all internal edges too
>>       5. yield a list of *all* affected edges by that route.
>>
>>
>>      -> all good up until here.
>>      next steps / options for me (as it is not wanted to write a modded
>>      network via sumolib
>>      - why allow modifications then at all?) are:
>>
>>       1. load net N as an xml
>>       2. scan all lane elements for neigh tags
>>       3. those not contained in the given list of affected edges lose
>>          their neigh tag.
>>       4. save the modified net.xml
>>       5. pray for good fortune and the blessings of an intact net
>>
>>
>>      summarizing question:
>>      will my network likely be intact after such a procedure?
>>
>>      thanks, best
>>      Gerald
>>
>>      _______________________________________________
>>      sumo-user mailing list
>>      sumo-user@xxxxxxxxxxx <mailto:sumo-user@xxxxxxxxxxx>
>>      To unsubscribe from this list, visit
>>      https://www.eclipse.org/mailman/listinfo/sumo-user
>>
>>
>> _______________________________________________
>> sumo-user mailing list
>> sumo-user@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
> _______________________________________________
> sumo-user mailing list
> sumo-user@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user