Constructive discussion of the concepts that the OSMPIE (approach) brings to the table

General talk
, ,
1

First, I’d like to apologize to the community for any impression that I, as the author, am ignoring them. This isn’t true; only one author and one topic were ignored. There was no point in responding to a thread where someone, without understanding the situation and perhaps out of anger, simply put their own spin on it in the title. Anything I say in that thread will be used against me.

There’s already a thread for orders to delete or disable it, and for accusations.

Therefore, I’ve created a new thread for questions, answers, finding the right solutions, and help. For the community that really wants to understand this and can and will help.

It’s also very important to keep in mind the language barrier and the complexity of the problem (intersections). And remember to use the correct names for certain things (junctions, intersections, etc.), tags, and so on. And that I or the translator may likely make some mistakes in this regard, whether during communication or text composition. Sorry.

2

Regarding proposals for new tags

What we’ve laid out in the documentation is a step toward preparing proposal drafts. However, I’m having both objective and subjective difficulties here. I was hoping for the community’s help. I need a guide. Not someone who’ll just shout, “Do it!” “Do it!” But someone who can point out where and what to ask questions of, and preferably someone who’s already done it. Even technically, the wiki is a thorny path.

Imagine someone registering with OSM yesterday. That’s roughly where I’m at. Anyone interested?

Adding to the complexity is the need to figure out what to propose.

For example, connect:lanes is a fairly straightforward concept, but adding placement is a question: should I write a new proposal or add something to the old one?

Tags junction:radius, junction:cluster:radius, junction:shape – is the correct namespace selected? I planned to address many similar questions in a discussion with you, and I hope it will happen.

I want my efforts to officially propose tags—there’s a lot of work involved here, and ChatGPT won’t do it for me—to be in vain. Why write a proposal if it’s clear they’ll reject it for formal or emotional reasons?

Therefore, the help of community members is essential here.

3

Regarding opensource

By introducing OSMPIE as a public and freely usable application, we wanted to thank the community for their work, first and foremost. This required a significant investment of time and effort. It’s already clear that the OSM tag model, with just a few tweaks, can deliver a quantum leap in HD road rendering and mapping. And that’s not something many people can do.

Moving to full open source will likely be a gradual process: first the editor, then perhaps the core itself. But of course, this approach will only take root in the OSM ecosystem and receive official support.

Regarding plugins and other editors, the API is open. I’m not a JOSM expert at all, so if anyone wants to develop a plugin, they’re welcome.

4

Request for help

We need someone willing to answer questions and help with

  • discussing and editing concepts and texts,

  • how to format a proposal, what the process is, where we made mistakes, examples, etc.

  • will try the editor and point out where something is forgotten, missed, or confusing.

Please help!

Let’s look at specific examples. Please provide more context in your messages, example links, and explanations. If you’re simply saying “do this,” that should be posted in the previous thread. Try making a “bake” in OSMPE, share a link to it, the changeset, the wiki, and point out the problem. If you have criticism, make suggestions.

5

Regarding osmpie: tags*

This is indicated on the application’s main page.

Снимок экрана 2025-12-05 в 11.39.40
Снимок экрана 2025-12-05 в 11.39.401920×1099 128 KB

osmpie:{tag} = any - overrides the values ​​of any {tag} for the object(nwr), but these tags are never sent to the OSM database, but are simply removed from the final changeset before.

These auxiliary tags were originally intended for the editor’s internal needs and for fine-grained rendering control.

6

New wine and old wineskins.

It’s clear to me today that the concepts we introduced with our release are tearing at the heartstrings of some community members. And to alleviate these pains (forgive us), a decision has been made that I would have liked to avoid, but…

In the near future, we will try to release in which all newly proposed tags and keys will behave similarly to osmpie:*, but will be stored in our own database and appended to all subsequent requests from overpass by object ID. Until the tag is officially recognized. If…

OSMPIE as an OSM editor will remain “white and fluffy” and will not violate a single line of your “law.” Although, who will cast the first stone? Any tag you like or…

Figuratively speaking, we will create a transparent augmented reality to the reality of OSM, but in our own new wine skin.

I didn’t want this to happen; this approach could be detrimental to the development prospects of OSM itself. Because it takes us back to the situation two years ago, when OSMPIE was a closed-to-the-public editor.

Thank you for reading this.

PS: I’ll split this into different posts in the thread to make it easier to respond. If you agree, give a like; if you don’t, give a dislike under each one.

Links

7

This document positions connect:lanes=* as a simpler alternative to connectivity relations because it avoids having to create multiple relations per intersection. In case you were unaware, this was the original idea behind the unsuccessful transit:lanes=* proposal. It tried to avoid relations as much as possible. Since it was introduced in 2015, that key never saw much use outside of a few locales. The proposal finally failed after relevant software projects insisted that it was a bad idea they’d never support.

The proposal did allow transit:lanes=* to appear on a relation, for connectivity across an intersection, but this was kind of an afterthought. I helped resurrect this part of the proposal, because it solved a real need quite elegantly in my opinion. The proposal for type=connectivity was successful because it goes on a relation, not despite that fact. In the last six years, it has seen much more adoption than transit:lanes=*, in part because editors have some support for it. While no router supports connectivity relations yet, for Valhalla this was merely a matter of unfortunate timing and a lack of support for placement=*.

I guess I’d be curious what the big problem is with representing the relationship between two ways as a relation, as this connect:lanes=* idea seems to reject the approach outright.

3 Likes
8

It continues to be a bad idea independent of if we insisted at the time or not.

In general the business logic for handling tags on ways during common operations (reversing, splitting and merging) is complex enough as is. Not only is it difficult to impossible to enumerate all the rules that need to be followed, at any time somebody can come up with a new scheme and will complain bitterly if editors “break” the tagging. For example Vespucci got code to correctly reverse conditional one ways in the last release, something that I had previously missed (when merging ways you may need to automatically reverse the drawing direction of the involved ways and in those cases you need to ensure that the one way still restricts the traffic flow in the same real-world direction).

In any case up to now we’ve managed to avoid tagging schemes for ways that use tags that are dependent on the tagging of neighbouring ways and would need hardwired code to handle the above mentioned common operations (likely special code per tagging scheme) and it would be a good idea to keep things that way.

2 Likes
9

To be more specific, it was described as a horrible tagging scheme not viable due to severe design issues by iD, Vespucci and JOSM developers, see [Tagging] I can't support transit:lanes and [Tagging] I can't support transit:lanes and #11054 (Tag and relation transit will be broken when splitting a way) – JOSM and they refused to support it.

As SC developer: feel free to add StreetComplete to list above. As seen from post above Vespucci has not changed their mind on this topic.

Also, I am willing to bet that if GoMap!! developer would be asked they would react the same.

Not sure whether I have seen such clarity on “this tagging schema is terrible” ever before or later.

BTW, I opened remove connect:lanes= as it terrible no good and bad tagging scheme · Issue #12 · kuzinmv/osmpie-doc · GitHub as Remove support for the experimental tagging invented here · Issue #9 · kuzinmv/osmpie-doc · GitHub is not very specific and covers many things at once.

10

Thank you for your response.

No, connect:lanes doesn’t deny the existence of relationships. I’ll share my answer from the interview.

The connect:lanes tag was proposed to the community for practical reasons. It does not replace relation[type=connectivity], just as the tag way[highway= + cycleway:right=lane] does not replace highway=cycleway. They coexist. connect:lanes allows conveniently setting connectivity as an attribute rather than creating a separate object. Example with cycleway 1 and 2. When you try to map the roads of an entire city yourself, you will be able to make a choice.*

The main reason for the emergence of connect:lanes was the need for a simple and unambiguous complement scheme to accurately indicate connectivity. A full implementation of the relation[type=connectivity] renderer is impossible due to the existence of via=way or multiple such members. This introduces ambiguity into the design itself. That’s why we quickly added support for relation[type=connectivity], where via = node, because there’s a one-to-one correspondence to connect:lanes.

The second, but probably most significant, reason is the cumbersome nature of relation[type=connectivity]. And the way[lanes] fall out of context. What does this mean? The difficulty of determining the number of lanes for a way—I don’t need to tell you, right? Taking into account directions, buses, parking lots, etc., the debate continues. And when we create a new object (relationship), we have to combine the input context of the attributes for the relation and restore the context from the required ways. This is difficult both cognitively and for creating a good UI/UX.
Doing everything in the context of a way, when the :lanes: schema data is right in front of you, is much more convenient.

It was difficult for us; we were looking for a simple alternative. Because our mapping practices differed from those of the average OSM mapper. Imagine you have a commission to create a road model for an entire country or a very large city. Where you use something to indicate connectivity not just once a year, but constantly.

Plus, of course, the overall complexity of the input. I find it very symbolic that it’s in a relation that’s been flagged in the wiki. This error has been around for several years.

You might also be interested in this discussion or find answers there.

11

Are you sure it’s impossible? This visual plugin for JOSM apparently supports multiple via members in a connectivity relation. Perhaps your architectural design makes it less straightforward to implement? The most complex connectivity relations I’ve ever had to map involved two via members, because the intersection was modeled as two dual carriageways shaped like :hash:.

Are you sure you aren’t overthinking things? I’ve never seen any situation like your example in real life. Two lanes of traffic crossing over each other while turning left? The connectivity relation syntax technically allows for it too, but it’s quite an edge case.

At least here in the U.S., we have a principle that cars shouldn’t run into each other. 1:1|2:2 is assumed when there are two left turn lanes. If the cross street has three lanes, then the rule is 1:1|2:2,3, but usually there are lane extensions (dashed lines) running through the intersection, so I map a connectivity relation. Only when the leftmost lane has a choice of two lanes does it become really necessary to map a connectivity relation with 1:1,2|2:3. Do the traffic rules differ significantly in another place that you were considering?

As I understand it, the lane indices in connectivity=* should be consistent with the numbers in placement=* and the number of pipe-separated items in turn:lanes=* and change:lanes=*, but all of these keys can refer to more lanes beyond the value of lanes=*.

Yes, it requires some gymnastics on the part of the data consumer. You’ve put forward an alternative that requires a different tradeoff. Regardless of the merits, you really should’ve engaged with this community about your tagging ideas before releasing an editor based on them for public use. Even now, reorienting the tagging scheme is a significant undertaking because of all the independent software projects involved.

Thanks for correcting my mistake. I hope you didn’t go through so much trouble to devise a new tagging scheme just because of a typo I made once while tagging something manually in iD, which doesn’t have any UI for lane-level tagging in the first place, while I was about to fall asleep at my keyboard. (I don’t even want to know how many turn:lanes=* and change:lanes=* tags I’ve flubbed in the same manner…)

1 Like
12

Very funny you tried to start a “constructive discussion” with such unconstructive presumptions

  1. There are 7+4=11 reacts, and 7 other comments, not only me and the 2 links
  2. You can respond to others, not me. I believe I have tried to understand the tagging by commenting extensively on all of them. Your proposal will be used by the average user. It will be how them understand it, not me who put some more time reading it. The doubts aren’t started by me, but a Discord discussion by others. Justifying not responding by assuming it “will be used against me” doesn’t make things better.
  3. I don’t see why a developer should see a Github issue using a verb form for a clear request as “orders”, “and for accusations”
13

Of course, I’m not sure about anything.
It seems we’re talking about different things. You’re talking about mapping habits, and I’m talking about data structures (relationship connectivity). When I said “impossible,” I probably meant “completely impossible” for rendering, not for storing data like in a storage environment. Because a data structure doesn’t contain important information about intermediate paths, which generally leads to either uncertainty or, as you correctly put it, “mapping traditions.”

https://osmpie.org/app/editor?pos=30.342679&pos=59.932077&zoom=19.67&bakeId=4c70935e-b404-4c8a-9be0-cf88cb8ede66

Let’s consider a simple, artificial example: a relation object that, on the left, goes through a via=way. The uncertainty lies in the fact that there are five (or perhaps more) possible paths. And with a large number of intermediate paths, the variability and uncertainty increases dramatically. The relation structure itself contains no data, and nothing or no one has provided any information to close it.
If we start fantasizing about what we need to add to member, I assure you, we’ll come to the simple conclusion that we’re overcomplicating the relation and it’s easier to create two or more, where via = node.

This example isn’t as far-fetched as it might seem at first glance. Telegram: View @tak_grubo

This was done as a joke (Easter egg) to keep the reader’s attention. It has no subtext. Although, there’s a grain of truth in every joke. Telegram: View @ruosm

I’m confused that we’re discussing more of the subtleties of relation[connectivity]. Maybe we should start a separate thread for that?

I’m very sorry, I didn’t mean to offend you personally. It’s not about the mistakes we all make every day. I just remember that moment vividly, when I wanted to understand why relation[connectivity] was so good, and I started with the wiki and immediately ran into the need to parse parentheses, commas, and | in a string and combine this with the context of the lines in each way. And I thought, wow, how complicated. And I decided to take a closer look at this relation on an unusual road sign. Especially since it was via a via=way.

14

Yes, hook turns are especially common in Australia, and the cycling equivalent is common in several other countries. However, a very important aspect of a hook turn is that cars don’t run into each other. While the hook turn lane proceeds into the intersection, the other lanes are stopped. Fortunately, a data consumer can already detect it using turn:lanes=*, by checking for through lanes on the “wrong” side of a turn lane. The trajectory of the vehicle through the intersection isn’t something we model in detail.

At Ulitsa Akademika Yangelya station, the bus lane proceeds while all the other lanes are stopped. This is an aspect of traffic signal operation rather than lane connectivity. After all, there’s nothing unusual about being able to change multiple lanes at a time, which we simply model as change:lanes=* on the way. We severely need new established tags to express signal operation, including signal phases and exceptions for turning traffic. This is the case even when all the streets involved have only one lane in each direction.

In case there’s any misunderstanding, the connectivity relation type is not intended to model every possible trajectory of arbitrary length. As long as we keep the relation limited to the ways immediately surrounding an intersection, the number of required relations remains quite manageable in practice. This is no different than how we model restriction and manoeuvre relations. The advantage of a relation, as opposed to tags on individual ways, is that editors and the OSM API can enforce certain constraints on the relation, and so that queries and QA tools can easily identify broken relations at scale.