Hey Nate, a small request to be a bit more conservative with the changes here. Galley east of Roncesvalles still hasn't been painted with the counterflow lane as of today, even though you tagged cycleway:left=lane 5 days ago. It was indeed painted west of Roncesvalles, and is indeed planned to be painted to the east, but as I understand it they're waiting for resurfacing after watermain work to be complete before painting.

I'm monitoring the progress on this project so no need to tag planned changes that haven't happened yet.

Notes from survey on site: I did not find the bicycle repair station in mapped location. I asked staff at the miniature railway and one of them thought it might have been here previously but was removed a long while ago.

For the record, per discussion in osm.org/changeset/153868089 , this changeset has been reverted in osm.org/changeset/154124509

Per this discusssion, I have reverted this changeset and changeset 153875016 in osm.org/changeset/154124509

Hey, thanks for adding the bike share locations via maproulette. Would be a great project to survey them, set exact locations, and clear the fixmes.

Hi -- thanks all the detailed surveying you're doing in Toronto!

Quick note about the change to surfaces here. You've been using surface=concrete:plates. This value actually refers to prefabricated concrete plates that are made offsite and then trucked to where they are needed and attached together with special ties or buckles.

The vast majority of concrete sidewalks and paths in Toronto are instead poured in place: liquid concrete is poured onto the ground in between formwork, then once it hardens a bit, dilation gaps (acting as very basic expansion joints) are cut into it. This gives the appearance of separate "plates", but the plates might be different lengths and there are no ties between them. So I think surface=concrete is the better tag?

See osm.wiki/Key:surface#Paved for details and photos. Let me know if this makes sense or if I have something terribly wrong!

Hello,

> As OSM doesn’t have a classification for non-residential local streets, I think “Residential” is the closest, but open to other suggestions – but I do think these roads should be classified.

OpenStreetMap *does* have a classification for non-residential local streets, and it is precisely highway=unclassified.

The name "unclassified" (like some other OSM details) comes from British terminology, where roads are classified as "unclassified" in the meaning "road too small for a classification number" (more minor than tertiary) in their national government classification scheme. Please check osm.wiki/Tag:highway=unclassified for more information.

highway=unclassified is a valid OSM tag which doesn't need "fixing" or classifying.

Roads or streets of truly unknown classification are tagged as highway=road instead.

Hello Jackson,

with the new mapping with separate ways, routing looks like a mess:

https://bin.piorkowski.ca/2024/2024-06-14%20bike%20track%20routing.png

(screenshot of osm.org/directions?engine=graphhopper_bicycle&route=43.6465%2C-79.4387%3B43.6653%2C-79.4094 right now)

12 instances of "turn slight right" / "keep right onto Bloor West Bike Track", and that's with the router actually giving up on the bike track for some of the distance (1100 m on Bloor Street West) - if it hadn't, there'd be even more of these instructions.

In reality, you turn onto Bloor Street West and continue straight. There is no "slight right".

I'm really not convinced this is an improvement, can you comment?

Hey, I had documented the tagging I used for these relations on osm.wiki/Proposal:Two-stage_bicycle_turn

If you have thoughts or opinions about this tagging, can you comment there, and/or update that wiki page with the tagging you changed?

Survey note: I explicitly removed "Pearson Airport Limo Toronto" osm.org/node/11978396314/history - I surveyed and found no signage for this business, instead the address given (451 Dundas W) is a UPS Store location advertising mailboxes among other services. (Added the UPS Store as osm.org/node/11980955328 )

I repurposed the limo node for the empty store next door (453 Dundas W) because the node was actually placed over that building.

Thanks!

Most of the "tracks" in Toronto are created without changing the roadway, by placing planters, pre-cast concrete curbs, and/or flex posts on the roadway. IMO this is borderline for "track", but it's different enough from the norm of painted lane that I don't mind cycleway=track tagging. But as it is on the same roadway, I'm not sure drawing a separate way for bicycles is worth it considering the downsides.

(There are _some_ spots where roadway has been rebuilt to separate bicycles more - Bloor Street east of Bathurst comes to mind - but they're few and might not be on aerial imagery yet)

For naming, if we were to go with separate ways, personally I would suggest to match the street name. The fact that it's a cycleway is already in highway=cycleway, and routers will use something like "turn right onto cycleway Richmond Street West" which seems better than "turn right onto cycleway Richmond West Cycle Track" because the former is the actual name of the street.

Another note about mapping if using separate ways - please consider avoiding merging into main way at intersections, per https://community.openstreetmap.org/t/mapping-dedicated-cycleway-on-pavement-temporarily-merging-into-main-road/113840/3 (but I would note that the discussion on whether or not to do this is avoided when cycleways are mapped on the main street way)

As you edit OSM please also keep in mind that different regions may have different tagging/mapping norms.

For the record, see previous discussion for Toronto in early 2023 osm.org/note/3498476

Hello,

Thanks for your edits to bike infrastructure in Toronto.

I was wondering what your motivation for the changes to map bike ways as separate tracks is? This was not previously used in Toronto for standard street-side bike lanes or tracks; bike track information was encoded using cycleway=* tags on the main road. This preserved information like the class of road or speed limit of the road the cycleway runs along.

Also to note, these are not called "Cycleways" in Toronto so the name tag is not really correct. Closest name is probably "cycle track" but it a description ("Danforth Avenue cycle tracks" as in cycle tracks along Danforth Avenue, not "Danforth Avenue Cycle Track" as a name) and not in any official names that I know of.

Made the change back to lanes in osm.org/changeset/151693506 after riding it myself

Hey there, quick question. In this changeset you've deleted some crossing=no tags, for example at osm.org/node/158701763/history

I was wondering if this was because a tool was complaining about them?

I've used crossing=no tags to reinforce where there is no pedestrian crossing at an intersection, because I found that pedestrian routers sometimes tend to leave sidewalks and use roadways to cross a bigger street at locations where there's actually no crossing. So if a tool is complaining or not supporting these, that would be good to know.

Sorry I see that it was from OsmAnd user, but same thing basically.

the species tags for the Roncesvalles surveys are verbatim from plaques in front of the trees

For the record, the species identification is by iNaturalist. I might tweak this, since something like taxon:en=* might work better?

correction to changeset message: "on west side of the street", not east

Hey Cameron,

We could use official_name=* but personally I'm not too sure of the value. Generally my gut feeling is that there isn't much use duplicating data from TTC GTFS that isn't directly used in OSM itself. So name=* yes, route relations maybe (some apps do use them), but official_name=* probably not? The most useful parts are probably name=* and ref=* which contains the TTC stop ID which matches GTFS stop_code.

GTFS guidelines in OSM were recently approved, you can take a look at osm.wiki/GTFS - it's a bit Euro-heavy, but my gist is we can add gtfs:stop_code=5425 to tie stops to GTFS (or just use ref=*, but I guess gtfs:stop_code=* is more explicit) and maybe gtfs:route_id=61394 to routes to tie them to GTFS. That might be useful to someone at some point.

I'm mixed on the "west side" thing for farside stops. Part of me wants to say that OSM is a geographic database so the fact that the stop is on the west side of the intersection can be computed. But then the reductionist argument is that most stops name could also be computed if the name is the cross street. So I'm not opposed, but still think that "what's announced on the bus/streetcar" is a good guide (when you're on the vehicle, you'll hear/see the stop name=* being announced; when you're finding the stop on the street via app, you can usually see its location on a map in addition to seeing the name?). I think in some cases TTC does announce "west side" in the stop names, especially when it's got stops on both sides of a large suburban intersection.

I'm not aware of any apps using tags like official_name=* or description=* for user navigation. I do know OsmAnd does use OSM public transit data if you want to give it a try - as far I can tell it uses only the stop name=* and the route ref=* and name=*, so the description=* won't necessarily help you.

For updates, in my experience transit routes generally don't change that much once mapped in Toronto (streetcar construction detours notwithstanding). I think not all TTC routes are fully mapped with PTv2 relations, and getting that in would be a benefit. Then mapping the 905 transit systems - many of them are there, but incomplete, or not updated in ~8 years and there have been rearrangements. On programming side, creating a QA tool that compares information in GTFS feeds or on agency websites with what's in OSM and flags differences for review would be cool! I don't know how much of stuff like this has been done for OSM already.