How to properly tag "Commercial Delivery Route"?

Dear US OSM Community,

We’re currently conducting an organized editing activity in the U.S. focused on truck-related tags, as announced here: OptimoRoute Organised Editing Activity in the United States.

We’ve encountered a case that isn’t well documented and would appreciate guidance, as discussed in the editing announcement thread.

In Fort Worth, TX, the Code of Ordinances distinguishes between truck routes and commercial delivery routes, as outlined in section 22-112 of the Fort Worth Code of Ordinances. According to the ordinance, truck routes are prioritized over commercial delivery routes.

For truck routes, we would typically use the hgv=designated tag. However, we’re uncertain about how best to tag commercial delivery routes. Streetside images show signs labeled “COMMERCIAL DELIVERY ROUTE”.

Since our team is actively working on the project and we’d like to avoid delays, our interim approach would be to tag these routes with both hgv=designated and a temporary placeholder commercial=delivery tag or goods=designated. Using goods=delivery doesn’t seem to be the right choice, as “delivery” is typically associated with allowing deliveries on a particular street rather than designating a through route.
Once we have a clearer tagging recommendation, we could replace the placeholder tags with the appropriate ones.

We’d appreciate any input on how to correctly classify these commercial delivery routes in line with OSM tagging standards.

Thank you for your guidance!

The OptimoRoute Team

I would not use any access tag neither for truck routes nor for “COMMERCIAL DELIVERY ROUTE”. Instead I would use new tags like truck_route=yes and commercial_delivery_route=yes.

Hi @skyper, thank you for your input.

I am not sure that the truck route idea is correct, as it seems to contradict the documented MUTCD/R mapping, specifically under R14 “Truck Routes.” The R14-1 sign, labeled “TRUCK ROUTE,” is indicated with the tag hgv=designated according to the guidelines.

Oh, you are right. I have to admit that I am not that much familiar with tagging in the US.
Still, I would not have used an access tag for these signs and as your project is not only about the US (as I have seen CS in Australia), you might have to find solutions for other countries.

Do other vehicles and transportation modes have less rights on these roads or are they purposely build for trucks? Would adding motor_vehicle=designated or even vehicle=designated be wrong? How do you tag “truck routes” with access restrictions?

@skyper, these would be standard roads designated for truck or commercial vehicle use by city authorities. Simply put, this designation means the city prefers that trucks avoid dense residential areas, using truck routes until they need to enter a residential street for a delivery.

As far as I’m aware, the hgv key is the globally recognized choice for heavier truck restrictions and access, while the goods key applies to lightweight goods vehicles.

@skyper, regarding the Australia comment, an Overpass Turbo query shows more than 4,000 ways in Australia tagged with an hgv tag.

In the U.S. and Australia, signs about “truck route”, “road train route”, “bike route”, and “wheelchair-accessible route” merely mean that the way is designated for the use of that kind of vehicle. These “routes” aren’t necessarily arranged in linear fashion, as one would expect of a route relation, although this can happen in some cases by coincidence. As far as I know, they do imply at least a yes access level; a “private” truck route would be a contradiction. Strictly speaking, these designations are more like official recommendations than access rights, but that’s a whole ’nuther discussion.

In Europe and possibly elsewhere, goods=* corresponds to a specific vehicle classification and a sign that matches. My understanding is that this is more or less a sprinter van or pickup truck. In the U.S., we don’t have access restrictions specifically about such vehicles. Instead, commercial vehicle restrictions apply to… commercial vehicles. This is a much broader category that can include tractor trailers, school buses, and even station wagons and sedans. Usually, this means any vehicle carrying commercial license plates, driven by someone carrying a CDL. But national parks only consider whether the driver is paid to drive the vehicle, and some states have alternative definitions based on weight and passenger capacity.

There has been talk in the past about spinning out a better-fitting commercial=* key, so that mappers don’t have to conduct legal research just to tag what the sign literally says. But coining a new access key in 2024 is a somewhat scary prospect and would need a careful migration path. So much software relies on hgv=*, so we can’t make it implicit overnight. For now, the documented approach is to tag hgv=* and goods=* together, and possibly tourist_bus=* and coach=* as well, hoping to catch anything that might be affected by the restriction.

A couple possibilities (using just hgv for brevity):

  • Based on the ordinance, it sounds like a trucker may use the street if there’s no other option, but despite the text on the sign, it isn’t strictly about making deliveries. As you note, hgv=delivery and hgv=destination could both be incorrect, because the trucker may be using the street as a connection rather than a final leg. hgv=discouraged may be a better choice.
  • Keys such as hgv:national_network=* and hgv:state_network=* exist because the federal government and some states distinguish multiple classes of trucks and where they can go. You could tag hgv=designated hgv:local_network=commercial_delivery with the understanding that this is such an edge case that most data consumers won’t understand the nuance around it.

@Minh_Nguyen, thank you for all the details and suggestions. This does seem like a challenging issue, and we’d definitely like to avoid introducing new access keys. For that reason, hgv:local_network might not be ideal, as there don’t appear to be any examples of this key in OSM. Similarly, commercial=designated doesn’t exist currently, and commercial as a key seems to have very limited use.

The discouraged value is intriguing, but it may imply “unsuitable,” which doesn’t quite fit here, as these roads are perfectly usable—they’re simply secondary to designated truck routes.

From our side, and considering this also as a data consumer, we’re thinking of distinguishing between the two by:

  • tagging “truck routes” with the usual hgv=designated,
  • tagging “commercial delivery routes” with goods=designated only.

I’ve noticed around 1,250 ways already tagged as goods=designated in OSM, though most (about 950) are also tagged as hgv=designated, which wouldn’t apply in our case. And as I mentioned, we’re open to revisiting these goods=designated tags later if a more suitable tagging solution emerges.

I’m not sure there’s any precedent for making this particular distinction. goods=* is complementary to hgv=*, not a superset of it. The ordinance doesn’t seem to distinguish between tractor trailers and vans. Maybe another option would be to tag the truck routes as hgv=designated and the commercial delivery routes as merely hgv=yes goods=yes. I don’t know of any mainstream routing profile that distinguishes between yes and designated, but I suppose yours could view designated as more emphatic.

I have a feeling that you’ll encounter many more local ordinances along these lines that will be more difficult to shoehorn into existing global tags. hgv:local_network=* may be unused so far, but it fits the pattern of other hgv:*_network=* keys, so keep it in mind for the future.

Thanks, @Minh_Nguyen. I will discuss this with our routing team.
The distinction between hgv=designated and hgv=yes, goods=yes sounds like an interesting proposal to me.

And you’re right, along the way, we might find more examples that shed additional light (or maybe even add more complexity! :grinning:) on the matter.

@Minh_Nguyen, here’s what we came up with, aligning with your last suggestion and maybe addressing your earlier points as well.

Truck route: hgv=designated

Commercial route: hgv=yes goods=yes commercial=designated

Why add commercial=designated?
The commercial key isn’t widely used, but its purpose is fairly clear, even though it was introduced very late in OSM. Currently, commercial is only used with yes as an access value, but designated is a well-established access value, so we think it fits here. We’re consciously avoiding delivery as an access value, or any mentioning of the word. As already discussed, delivery typically suggests a non-thru street, which doesn’t apply to the targeted roads in Fort Worth. These roads serve as secondary preferred routes en route to other destinations.
Using commercial=designated as a new key-value combination would also allow us to quickly identify and adjust these entries later, if needed.

Why not add hgv:local_network=commercial (or a similar variant)?
This option would introduce both new keys and new access values, which felt too much of an outlier for now, so we opted not to use it at the moment.

Ok, if these routes are officially signed, designated might be an option. I just want to make sure you do not stumble into problems, like we have in Germany with designated, shared foot-cycle-paths in areas with further access restrictions.
I still wonder if you also add bicycle=designated if there is a bicycle lane and foot=designated if a sidewalk exist?
In the car focused US (it might have changed a little lately) would that mean almost all roads should be tagged motor_vehicle=designated even without a sign?

In my eyes using hgv=discouraged would be the better solution or using other tags like your “network” tags.

While these two categories might globally be recognized there are many countries which do not distinguish between these two categories in traffic laws and only have a sign for hgv=no.

I am only talking about hgv=designated on highway=*. For sure you will find hgv=no in many countries.

In Germany, there is no sign for hgv=designated except for some parking areas, at the customs at boarders or at toll booths and goods=* does not exist at all. In fact, I am pretty sure this is true for many European countries.
Still you will find them in the data but most of them are just tagging mistakes.

I do not think this is a smart idea as hgv=yes and goods=yes are most of the time the default and do not have to be added but can be added to most of the roads and it does not help in defining “Commercial Delivery Routes”. Yet, again we do have countries where goods=* is not defined at all in OSM.

After all, I wonder if you are interested in finding a global solution for tagging and routing software or if you are only interested in certain countries?

Be careful here. While the usage is still low, commercial=* seems to be used as subkey for landuse=commercial or building=commercial and only twice on highway=*, see commercial | Keys | OpenStreetMap Taginfo.

It would be much easier to use a new tag which even can be changed later, if we find a better fit or tagging schema.

Yes, I’m acutely aware of this problem. Access tags are supposed to answer the question “Can I go here?” or “May I go here?” within reason, whereas these “route” signs answer the question, “Is this the ‘best’ way to go?” (Sometimes it’s the “best” way because it’s the only allowed way.) Still, for better or worse, the U.S. community has been using *=designated because the value is pretty well established. Eventually, if we come up with something better, the migration path will still leave a trace of *=yes, which wouldn’t be wrong.

Yes, in theory anyways. This gets into the issue of implicit defaults – another unending debate in which everyone is right, sort of. And is there any nuance between an explicit *=yes and an implicit *=yes? Technically, there’s no difference, but in that case, why do people tag foot=yes anywhere? Maybe it’s the difference between a pathless path and a pathful path?

Actually, no, we wouldn’t tag foot=designated on the roadway if there’s a sidewalk, because of course the sidewalk would be mapped as a separate way… right?

:face_with_head_bandage:

You have a point that commercial=* would become a homonymous key, though that already seems to be the case with some other access keys, such as emergency=* and bus=*. At least the existing usage is only as a secondary key, not a primary key as in emergency=*.

I only floated commercial=* as the most obvious translation of “commercial vehicles”, along the lines of agricultural=*, but there are other possibilities. For example, commercial_vehicle=designated would avoid any potential conflict. Or we could relegate it to a conditional variable, as in motor_vehicle:conditional=designated @ commercial. Mappers coin new variables on the fly all the time, but unfortunately conditional restrictions only enjoy very limited support in data consumers, even for much more common cases.

I agree. Even if this restriction relates to deliveries, *=delivery is likely to be interpreted too literally.

Fort Worth’s commercial delivery routes remind me of how a city near me, Palo Alto, distinguishes between through and local truck routes. We generally tag “Local Traffic Only” signs as motor_vehicle=destination, but the problem is that most routers only consider the subgraph of similarly tagged ways as the “destination zone”, whereas Palo Alto’s city ordinance defines local based on the city limits, including plenty of streets that allow trucks unconditionally. (We were only barely able to use destination for the restrictions around Dulles Airport near Washington, D.C.)

As if that weren’t complicated enough, Palo Alto defines a custom “delivery zone”. A truck (locally defined as a vehicle over 7 U.S. tons gross weight) can only use the road ahead if it has just come back from making a delivery in the business district shaded on the map:

I suppose in theory this would be some kind of enforcement relation, but I haven’t been able to ascertain the boundaries of this delivery zone. The law simply references this map, but the map is vague and not to scale. Of course, there’s no guarantee that any mainstream data consumer would be able to utilize this information even if we could model it properly.

1 Like

@Minh_Nguyen, we’ve found a similar example.

New York has a specific definition of a Local Truck Route, which closely resembles Fort Worth’s “commercial route” as a secondary preferred truck route. These are represented as blue roads on the NYC Truck Route Map.

For these routes, NYC in OSM has a lot of hgv=local tags, which the OSM Wiki on Key:hgv mentions as undocumented. In my opinion, the wiki incorrectly suggests that ‘local’ might duplicate the meaning of hgv=destination.

While we don’t plan to edit the NY area as it appears to be well-tagged, it seems like a potential way forward to update the OSM Wiki to properly define hgv=local as indicating a secondary preference of lower priority than hgv=designated. Following this, we could continue using the hgv=local value for Fort Worth instead of hgv=yes.

Nice find. The tag is mainly used in New York City and a handful of other cities, but it’s been around for years, and Valhalla even declares support for it. With over 10,000 occurrences, it would be considered at least “in use”, if not “de facto”. It’s probably worth some further investigation to determine whether the existing usage really does refer to local through routes as opposed to “Local Traffic Only” situations.

NYC government is rather clear for these roads (check the NYC Truck Route Map):

Local Truck Route: Trucks with an origin or destination for the purpose of delivery, loading or servicing within the respective Borough, shall only operate on designated local routes, except that an operator may operate on a non-designated street for the purpose of arriving at their destination. This shall be accomplished by leaving a designated truck route at the intersection that is nearest to their destination, proceeding by the most direct route, and then returning to the nearest designated truck route by the most direct route. If the operator has additional destinations in the same general area, they may proceed by the most direct route to their next destination without returning to a designated truck route, provided that the operator’s next destination does not require that they cross a designated truck route.

Yes, I was referring to the usage elsewhere.

Did you mean the below?
Out of the 10k hgv=local tags existing in OSM, 98% of them is in NY. There are like 150 tags elsewhere.

Yes, I was referring to those 150. Normally, I don’t think we’d have to be concerned about a long tail of miscellaneous usage, but since truck access is relatively sensitive, maybe a spot check would be a good idea before documenting the predominant definition.

I’d also suggest adding a clarification (also anywhere *=destination is discussed) that that *=local does not correspond to the more typical “Local Traffic Only” signs, since that would be very easy to confuse.

@Minh_Nguyen,

I took a look at all those 150 instances. To me, this seems very random, with no clear pattern outside of NYC:
• One short connecting segment on Long Island
• A few remote short roads east of Binghamton, NY
• One short connecting segment south of Vancouver, Canada
• One short lane segment in Montreal, Canada
• Two short remote road segments outside of Montreal, Canada
• One remote short road on the Island of Newfoundland, Canada
• A few remote short roads in the UK
• An occasional short road segment in Europe, very random
• A few very short segments in São Paulo, Brazil

Would you suggest that we edit the OSM Wiki documentation to reflect this? I’m not sure what the process for that would be.

Also, would you think it’s OK for us to use hgv=local in Fort Worth instead of hgv=yes (while keeping the other tags mentioned earlier)?