Yes, the code is closed, and we don’t yet understand why we should open it. There are also some technical difficulties – OSMPIE has grown out of our products and is now a separate application, but a mono repository complicates things.

Thanks… we’ll definitely add information there when we figure out what needs to be written there. )))

There are three key components to OSMPIE: - OSM sematic model parser - Estimate (Heruistics) - Rendering

And currently, 2 & 3 are hardcoded, meaning the end user has no control over these processes. The user can only influence the structure of objects and tags.(1)

Of course, we realized almost immediately that some customization would be needed to ensure the user sees the closest possible result, depending on the location they’re in.

For example, bus stops (platforms) in Germany and the USA are rendered backwards from the stop position, while in Russia, they’re typically rendered in both directions (backwards and forwards). There are countries that adhere to the Vienna Convention, and there are all the others, plus, of course, right-hand traffic, with its own nuances. + Different types of markings that perform the same functions. For example, in Russia, bus lanes are separated by a solid line, while in Germany they may not be separated at all, or by a dashed line, etc.

Therefore, we assumed that there would be some complex settings for each user that would affect both rendering and estimation. But this was impossible to achieve in the first version. This is only for the community that is accustomed to this type of app and understands the concepts. In the first version, we tried to simplify the UI, entities, and settings as much as possible.

Hello, sorry, but the system isn’t yet fully adapted for left-hand traffic. We understand this, and I think we’ll work on it as soon as possible (but it’s a complex task).

As for how to render a situation where the number of lanes isn’t marked at all, even though it’s a two-way road, based on our limited experience with mapping and various options, we’ve adopted the one that’s common in our area.

As a rule, these roads don’t look like the ones you’re showing. The one you’ve shown is a more complex intersection, and osmpie just pointed out that more tags are needed to ensure the display is correct.

We’d be grateful if you could provide links or examples of roads where lanes and onways aren’t marked, and how such a road would be correctly displayed in most cases.

I would be grateful if next time you add a link to bake (or bakeID), sometimes it’s difficult to find the place from a screenshot.

https://osmpie.org/app/s/ed00be681dd642cdbebf076a07e194bf

https://osmpie.org/app/editor?bakeId=dde9a875-c8f5-4624-8801-d011f2fe08ee&pos=7.61563&pos=46.770444&zoom=20.55&tile=Esri+World

seems it the same placement:transition ?

I suggest going to GitHub so as not to fill these comments with links

https://github.com/kuzinmv/osmpie-doc/issues/2

It’s hard for me to say, I’m new to OSM and don’t really understand what’s right and what’s not. We used the experience of this proposal

osm.wiki/Proposal:Placement

and to be subtle, here’s an example, and in general it seemed reasonable to me, and that’s why we’ve implemented it this way at the moment.

osm.wiki/w/images/4/47/Lane_Placement_2.png

I partly understand that this is unnecessary fuss with splits and short ways, and of course I’d like to have a smart renderer that doesn’t care whether there’s a transition or not. I think we’ll get to that.

Example:

https://osmpie.org/app/editor?bakeId=d2abe506-3c01-402e-85e8-d0bb69b39237&pos=7.62938&pos=46.756614&zoom=20.00

Hi WilliamHarrison, can you share the link here or the bakeId ?

But I think that guess what you’re talking about. Probably need to split the ways and add placement: transition to short parts, wich linked to node

placement=transition

Roundabouts are of course a serious challenge for rendering, since they are mapped as anyone wants. In any case, it will be more productive to discuss a specific example

Thanks!

Good day to all!

Thank you for your feedback, and I want to please you a little. We are working on the official launch of OSMPIE

The application itself is now available online, as well as some documentation, descriptions and cool examples.

https://osmpie.org/

I’m also actively trying to introduce corrections to the OSM roads.

There you can see links to changesets to compare before and after and see which tags were used where.

There are still a lot of bugs in the editor and engine, but it is already quite usable.

That is why we suggest you try it now and of course we are waiting for your comments and issues on GitHub.

If you don’t have a github, then you can send me a private message or telegram(@mikhail_kuzin), or whatever is convenient.

I look forward to your questions and suggestions. Thank you.

Hello, Baloo Uriza!

I see that you have been mapping for a long time and a lot. And you have a lot of experience with roads and are one of the few who use relation:connectivity.

I would like to ask you, could you write your opinion about such an alternative for indicating connectivity at intersections. connect:lanes

Using this changeset as an example.

There are two viewing modes (right half) “Polygons and marking” and Connection frame - for checking connectivity.

Although these are quite old edits, but perhaps you will remember. I deleted all the relations and replaced them with these tags. There are also a number of other tags that are help a perfect rendering of the intersection.

I would be very grateful to you.

It was hard to implement the logic for cars and roads correctly, but for bicycles it is still 10 times more complicated. Considering that in OSM you can tag as a cycleway:* near a regular road or a separate path.

But this does not mean that this should not be done. For now, we have not yet included the rendering of bicycle paths - since it is very unstable and glitchy.

But the pedestrian (highway = footway + footway = crossing) part at the intersection is worked out quite well.

We will get to bicycles if the editor is in demand by mappers.

Hi, thanks for the nice overview of your experience. We are working on intersections and their mapping and are planning to release a specialized editor with improved visualization soon.

Which also touches on the issues you raise. I made a small example of different methods, in the area you indicated. I hope this set of changes will be useful and interesting to you.

both_ways + buffer lane example

To solve one of the problems, we propose to expand the understanding of the placement tag. And then very interesting opportunities for precise mapping of lanes and their relationships open up.

placement extension

Thank you for your article.

@WilliamHarrison Thank you, we will definitely check in the areas where you recommend. I will let you know about the results as soon as they are available

Javascript is also there. I didn’t quite understand about the pedestrian crossing, but in any case here is the link

A little patience, you will soon be able to test everything yourself.

Пока нет, релиз планируется осенью. Редактор довольно сложная штука и маршруты ОТ же еще добавляют функционала не целевого. Пока только почитать, обсудить, помочь добрым словом.

Тогда вот вторая, но на самом деле первая часть, которая многое расставит на свои места, возможно.

OSMPIE - OSM Perfect Intersection’s Editor

А если попробовать ответить на вопрос “зачем?” по существу.

Задача была провести-создать первичную классификацию junction, при этом желательно минимального размера, чтобы отделить такие типы точек, которые заметно влияют на визуализацию связных с ними элементов.

Например:

• https://wiki.openstreetmap.org/wiki/Tag:junction=inout - очень много в Спб сервисов выходит прям на основные дороги и понятно, что parking:{side} = lane нужно прервать в “районе” таких точек, а в районе = controlled вероятно будет вообще другое отображение парковок. + Если будет разметка divider то ее надо прерывать в районе таких точек.
• https://wiki.openstreetmap.org/wiki/Tag:junction=controlled - ну чисто логически - uncontrolled же есть + опять же если мы как-то захотим отразить стоп-линии или приоритет, то на регулируемых там светофор и понятия уступи дорогу нет, для каждого подхода к пересечению нужна стоп-линия. А вот на нерегулируемых только для уступи дорогу. Те после вычисления приоритетности, которое надо проводить, а для controlled необязательно.

Здравствуйте!!!

О Спасибо за комментарий! Это пока(вообще) не предложение схемы.. Я просто подумал что раз дневник, то пиши что хочешь.

Это первая часть из множества мыслей собранных более менее в кучку.

Я и не надеюсь, пока, что это станет реальным предложением для картирования. Потому что все вычисляемое - понятное дело. И для картирования не имеет смысла в текущей ситуации.