Closed droogmic closed 2 years ago
Lane separators as lanes -- hmm, yeah, that is sounding like a nice representation. That would also handle representing a dual carriageway with some large grass / concrete median as one set of lanes.
I wonder if that leads us to a per-lane property about whether different people/vehicles can move left or right. For example, moving between a cycle lane through some plastic bollards spaced apart to a travel lane may be possible for cyclists (with some sort of penalty), impossible for cars. Or when a road has a center-line marked as "no passing", we can represent that, vs "over-taking in the opposite direction allowed here"
Pulling in @enzet and @kfarr for thoughts too
Lane separators as lanes
@dabreegster yes as a practical matter this is how 3DStreet handles rendering lane separators -- we first parse segments from Streetmix, and then we insert "0-width" segments with different variants such as "double yellow", etc. It has worked out very nicely and it also opens the door to allow editing of the 0-width segments for the user to easily change striping variants (when we add planned editing features)
I will rewrite this proposal asssuming any non-zero lane seperation is itself a lane, and see what it looks like.
@droogmic, if it'd be helpful to have a brainstorming session by videocall with @kfarr or anyone else, let me know and I can schedule something. I think different people have been thinking about similar problems for a long time, it's awesome to see real progress happening now! Also fine with async communication like we've been doing
@droogmic, if it'd be helpful to have a brainstorming session by videocall with @kfarr or anyone else, let me know and I can schedule something. I think different people have been thinking about similar problems for a long time, it's awesome to see real progress happening now! Also fine with async communication like we've been doing
I don't mind (I get enough of that with work ;) ). I'll let you schedule and chair a call if you think it is necessary. For now I am happily making incremental progress :P.
Ok, so I now have a rewritten test set, as well as a rewritten python implementation.
@dabreegster, now is the time for a decision on whether or not to proceed (including a video call if helpful)
To be clear, I am not happy with how big this has become :( necessary evil?
A bit worrying merging such a big change, but I guess we can always revert if needed... Ill merge this when I get back tonight.
Nothing in production is using this yet, so merge whenever
On Sat, Jan 22, 2022, 11:20 AM droogmic @.***> wrote:
A bit worrying merging such a big change, but I guess we can always revert if needed... Ill merge this when I get back tonight.
— Reply to this email directly, view it on GitHub https://github.com/a-b-street/osm2lanes/pull/22#issuecomment-1019193594, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMWLF3MT5BHBLNLH2MXDOTUXKHHDANCNFSM5L35MOLQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
On that note, I would like to make steps towards including it as a dependency in some existing application, because it would give the feature development more focus. Would that be abstreet or something else, and what are the missing features to get it ready for that?
On Sat, 22 Jan 2022, 15:48 Dustin Carlino, @.***> wrote:
Nothing in production is using this yet, so merge whenever
On Sat, Jan 22, 2022, 11:20 AM droogmic @.***> wrote:
A bit worrying merging such a big change, but I guess we can always revert if needed... Ill merge this when I get back tonight.
— Reply to this email directly, view it on GitHub <https://github.com/a-b-street/osm2lanes/pull/22#issuecomment-1019193594 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAMWLF3MT5BHBLNLH2MXDOTUXKHHDANCNFSM5L35MOLQ
. Triage notifications on the go with GitHub Mobile for iOS < https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
You are receiving this because you were mentioned.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/a-b-street/osm2lanes/pull/22#issuecomment-1019284680, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACEL2ZZKPOVGGFIIZUSORIDUXK7U5ANCNFSM5L35MOLQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
Would that be abstreet or something else, and what are the missing features to get it ready for that?
I agree we're getting past the point of this just being an experiment. One idea is taking the nice web app and loudly announcing that. It may get more use/attention once it's glued to a Streetmix-like editor, or something that can render a bunch of roads in an area. So we're not really close to that stuff yet.
It's always been my intention to cut A/B Street over to this. There's a bit of maintenance cost to working with two separate git repos, but it'll be fine. For local development when osm2lanes might affect A/B Street, I can just pin the dependency to a local copy.
In terms of what it'd take to cutover... the main missing feature is lane widths. The current implementation is pretty simple -- and bad: https://github.com/a-b-street/abstreet/blob/0367a7238c7257a30d63b7be9c368d4346572b68/map_model/src/objects/lane.rs#L495
I think we could generalize this better by encoding this in the Config
struct somehow, and including some default "profiles." I'm sure in some countries / cities, people will contribute more details in the form of official design manuals or informal typical values.
To ease the A/B Street codebase into this change, I'll probably also preserve the current approach of bidirectional lanes being split into two one-way pieces, but that transformation can live over there, until I come up with something better in the simulation / UI layers.
Another difficulty will be handling pedestrian-focused spaces; A/B Street currently pretends those are cycleways with tiny walkable shoulders. That's a hack driven by older priorities, but yet to be cleaned up. I think also that can be papered over outside of osm2lanes
. So in general A/B Street will probably be the most complicated consumer, burdened with some legacy decisions, and have pre/post transformations that ideally get cleaned up over time.
Another idea is adding a feature to 3D Street to take an OSM way ID, download it with Overpass, run through osm2lanes
, and transform that into 3D Street's version of lane specs. @kfarr, interest from your side in doing that soon?
@dabreegster quick answer yes, long answer it would help to chat to review the high-level workflow and capabilities, and ensure this all fits in line with our goals.
In the mean time, I'll keep working towards adding capabilities and displaying them in the web viewer
I think the current spec is a bit brittle if we want to be truly agnostic to our clients
Adds: designated vehicle - to help renderers use - to inform on access restrictions by use case. width: to describe width of the lane.
Open issue: Something I have been mulling over in my head is whether we shouldn't make all lane separators be just a variant of lane. Because what is the difference between a painted line, 2 painted lines, 2 painted lines with some more space in between, 2 painted lines with hashmarks inbetween, bollards, etc. IMO it will become important to describe in full detail what kind of vehicles can cross, e.g. for overtaking, and how wide the space is.