Complaint and criticism against OSMPIE for redefining and promoting poorly thought tags without discussing and annoucing clearly

General talk Tagging general discussion
,
1

As there’s not another post on the forum, I will open a new one here OSM Perfect Intersection Editor - обсуждения
From discussion, it was found the recent launch of this new editing softwarehasn’t fully described its scope and impact https://www.openstreetmap.org/user/Mikhail Kuzin/diary/407577
This is made worse by looking at its documentation in detail osmpie-doc/en/perfect.junction.md at master · kuzinmv/osmpie-doc · GitHub

  • placement= : What’s noticed by others, a =dist:* for the distance from centerline was proposed instead of using the lane number. This would break existing applications, and editing software including JOSM’s lane style. While a different placement:distance= could be discussed, I suppose the intended method is placement= + width:lanes= indirectly. Coincidentally, a similar idea was asked on /r/OSM recently. Reddit - The heart of the internet
  • junction=
    • =controlled : Misleadingly defined to be signalized only, while =uncontrolled means no =give_way and =stop either. Overlaps with proposed junction=intersection , which isn’t discussed, nor seemed to be considered.
    • =inout : Mixes up orthogonal aspects of highway=service (other roads can be RIRO / right-turn only), right-in right-out (other highway= roads can be RIRO), and right-turn only (a junction can be right-turn only without having physical channelizing island as a standard RIRO would)
    • =joint : Unclear whether merges only, or include 2 one-way roads “joining” to be 1 in an otherwise standard intersection layout. Seems to suggest the opposite is needed with diverges.
  • junction:shape= : This is not shapes of all junctions (eg =roundabout ), but intersections only. Again ignores the junction=intersection proposal.
    • =rectangular , =oblique : It’s not justified why this can’ be detected programmatically, and how to distinguish between unchannelized and channelized (to become right-angled entry) oblique intersections
    • =staggered : This means 2 T-intersection next to each other, not a single offset intersection. I believe junction=intersection handles this implicitly.
  • junction:radius= , junction:cluster:radius= : Such extra artificial constructs has not been justified. If the user is asked to measure a bounding circle in those complicated case, spiting, or drawing the polygon doesn’t seem to be more effort, while that actually models the intersections exactly
  • connect:lanes= : Invents another new standard merely because the application doesn’t support type=connectivity , and doesn’t weight the pros & cons that led to that to replace transit:lanes=
  • osmpie:*= : Blatant Tagging For Rendering for an application

It’s very irresponsible to one-sidedly suggest changing existing tags to make your own application work. The lack of communication also caused these bad ideas to be cooked up in a room.

7 Likes
2

In general they don’t really seem to have to considered that things will still be edited by “conventional” editors that for now do not know about their tagging and doing so will as a tendency break everything that is not aligned with current practice (I’ve already noted the issue with trying to replace connectivity relations).

1 Like
3

This tag isn’t sent to the OSM database. But yes, it’s a UX issue with the editor that you see service tags.

1 Like
4

Have you considered opening issue at GitHub · Where software is built ?

As OSM-software author I would prefer to have chance to fix issues before getting “your software is bad” thread. (though on other hand if software breaks OSM data people are entirely allowed to complain about it in places they have chosen)

(not investigated are raised issues fixable or is entire projects structured in way that makes fixing those impossible)

2 Likes
5

I read closed vs open source was discussed, and not accepted by them yet. This made me doubt on how much influence can be made there. I’m not asking to them open source, but the closed source seems to suggest they want more control on their own. Some proof of public opinion would help.
It’s not exactly the software is bad. Quite the opposite, it may be very good. But the great powers come with great effect. The software has implemented much misguided thoughts. I see this as a conceptual problem first, before technical (ignoring how to actually solve these layouts without those broken tags), making the forums appear more appropriate than Github.
Furthermore, I want to warn people not to use these tags, if they aren’t familiar with the status quo, or if the software wasn’t clear it’s experimental and a “private venture”. It doesn’t seem much different if I opened a ticket on Github first, then post about it here.
Personally, I haven’t decided how to politely tell them to change everything on their repo. Perhaps it’s ironic for me to escalate the issue here first. But you can also take it as my grumbling against it, and brush it off if it’s too much.

2 Likes
6

Ok done Remove support for the experimental tagging invented here · Issue #9 · kuzinmv/osmpie-doc · GitHub

2 Likes