From: Amie L. <ami...@go...> - 2010-03-03 13:43:13
|
Dear Daniel, all, thanks for the hint with user-defined connections. I will check this out. Meanwhile, I started implementing the "no...-restrictions" and put them exactly where you proposed. I tried this by removing ingoing/outgoing edges from the appropriate from- and to-nodes. However deleting is not the right solution... Imagine a "T-Crossing", two horizontal edges E1 and E2 connected at junction J with one vertical edge E3. The restriction is of kind "no left turn from E3 to E1". J is the fromNode of E3. The straight-forward solution to delete E1 as inbound edge from J for sure produces the error that now there will be no connection from E1 to E2. I noticed "NBConnectionProhibits myBlockedConnections" in NBNode, but could not really figure out how it is exactly used. Maybe I could use this structure to model restrictions? The next problem is "edge duplication" because of opposite driving directions. In OSM it is likely that E1, E2 and E3 are single edges with lanes for each driving direction. SUMO netconvert handles this by duplication, it creates -E1, -E2 and -E3. It is likely that the restriction is "no left turn from E3 to E1" in OSM, but should be "no left turn from -E3 to -E1" in SUMO. I'm not yet sure how to handle this correctly in any case... Third problem - worst of all - is that OSM digitizers do not obey OSM definitions: For prohibitions the OSM website says something like: If the restriction is of kind "no", then there is no driving from "from" to "to". Many of the prohibitions I found were modelled like imperative restrictions: "only left from 'from' to 'to'". I wonder how the TAPAS project modeled restrictions!? Cheers, Amie ...of course I'll provide a net and the code if I ever manage to get this working. On 2 March 2010 11:29, Daniel Krajzewicz <d.k...@go...>wrote: > Dear Amie, all, > > > 2010/3/1 Amie Lukas <ami...@go...> > > Dear Developers, >> >> OSM provides support for relations. They can be used to model turning >> restrictions, like "No Left Turn" or "Only Straight On". I tried to add >> support for this feature to SUMO netconvert. I'm already able to parse the >> restrictions, but I'm not quite sure where the right position for handling >> such restrictions would be. >> >> At first glance, NIImporter_OpenStreetMap::insertEdge seemed like a good >> place, however, after some trying this seems not correct, since many >> NBEdges >> have no incoming or outgoing edges in their from- or to-Nodes. >> >> > Why not? Because they have not yet been imported (like an edge is > referenced before being read)? Or because they are prunned? > > > >> What are the alternatives? >> >> 1.) NILoader::load >> 2.) NBNetBuilder::buildLoaded >> 3.) NBNetBuilder::compute >> >> I think "number three" would be a good solution, but I'm not quite sure >> which classes I should adapt to hold the restriction information and the >> method itself (NBEdgeCont?) and what call time would be good to enforce >> the >> restrictions (before removeDummyEdges?). >> >> > I suppose you should take a look at how this is done when reading > user-defined connections from "native SUMO-XML connection files" - aeh, > those are described at > http://sourceforge.net/apps/mediawiki/sumo/index.php?title=Building_Networks_from_own_XML-descriptions#Connection_Descriptions > . > > the class which is used for parsing them is > src/netimport/NIXMLConnectionsHandler. Now, I supose that the import of > OSM-connections should be very similar, because if a "native" connection > outgoing from an edge is read, all other are invalidated, and only the read > ones are used. Ok, there might be a problem if someone wants to prohibit > (remove) a connection to the next edge. In this case, you have to determine > the list of possible edges, first, and then remove the forbidden ones. BTW, > I think that setting connections should be done directly in the OSM > importer, after instantiiating the nodes and edges (before the line " /* > Clean up */ > "). > > Of course, we would be very happy about getting the modifications so that > we can insert them into the SVN - oh, a test net where they are used would > be nice, too. > > sincerely, > Daniel > > > > >> I hope you can help me out, since correct treatment of restrictions would >> be >> realy helpful. >> >> Cheers, >> Amie >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> sumo-devel mailing list >> sum...@li... >> https://lists.sourceforge.net/lists/listinfo/sumo-devel >> > > |