a-b-street / osm2lanes

A common library and set of test cases for transforming OSM tags to lane specifications
https://a-b-street.github.io/osm2lanes/
Apache License 2.0
34 stars 2 forks source link

Rewrite Spec #22

Closed droogmic closed 2 years ago

droogmic commented 2 years ago

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.

dabreegster commented 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

kfarr commented 2 years ago

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)

droogmic commented 2 years ago

I will rewrite this proposal asssuming any non-zero lane seperation is itself a lane, and see what it looks like.

dabreegster commented 2 years ago

@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 commented 2 years ago

@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.

droogmic commented 2 years ago

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)

droogmic commented 2 years ago

To be clear, I am not happy with how big this has become :( necessary evil?

droogmic commented 2 years ago

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.

dabreegster commented 2 years ago

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: @.***>

droogmic commented 2 years ago

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

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: @.***>

— 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: @.***>

dabreegster commented 2 years ago

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.

dabreegster commented 2 years ago

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?

kfarr commented 2 years ago

@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.

droogmic commented 2 years ago

In the mean time, I'll keep working towards adding capabilities and displaying them in the web viewer