@RobJN I’m working on that now

@matheusgomesms I think it only lacks administration and moderation features (reporting users, etc.). These will be worked on after public testing starts.

Dla mnie głównym motywatorem jest walka otwartych danych z zamkniętymi mapami (Google Maps, Apple Maps, HERE itp.). Produkty, które nie skupiają się na zarobku na klientach, są zazwyczaj lepszej jakości, ale przez ograniczone fundusze nie są w stanie wygrać marketingowo. Dlatego moim celem jest usprawnienie mapy OSM zarówno pod względem jakości danych, jak i interfejsu, aby była jak najlepsza dla przeciętnego użytkownika oraz programistów i analityków. Chcę ograniczyć wpływy wielkich korporacji.

@Hedaja I am getting inspiration from https://kagi.com/signup (which has a great modern and minimal design), and you can expect a similar experience on OSM-NG mobile version 😃.

How do you handle user not accepting T&C etc.? I think that’s intended that the user doesn’t have a choice in the Ruby implementation.

It’s a browser required field, so the browser nudges the user to make a conscious decision of accepting the terms. This ensures they don’t accidentally miss the terms.

@Hedaja Awesome to hear that!

We now actually use SVGs, but they are rasterized before being shown on the website (at a resolution we see fit). Previously, many icons didn’t have an SVG counterpart and were low-res, so this wasn’t possible to do. The actual work item was to create SVGs for them.

Why not just SVGs? Rasterized images are minimally larger in file size but noticeably improve website responsiveness as they are faster to render. SVGs are computationally expensive for the clients, which matters even more when you have lots of them.

@raincandy Of course, this is quite a popular idea :-) https://github.com/openstreetmap-ng/openstreetmap-ng/issues/24

Yup! When it reaches the feature parity point.

👷‍♂🏗🚀

:-)!

@sus242424 Currently it’s just a community project but we are working hard on making this a reality! There’s still some work needed to achieve the feature parity with the existing website. Just then we’ll be able to discuss it seriously 😉.

The problem I am trying to tackle with the new design is that pressing (X) causes the alert to keep coming back up again as soon as you move the map slightly, which is annoying if you don’t know what’s happening. I want to provide an easy way to completely turn off the data layer for users who may have accidentally turned it on or no longer need it. Binding this new behavior to (X) would be confusing because it’s not just a simple dismissal. If you want to simply dismiss the alert, zoom in on the map or change the view.

The original alert had only 2 outcomes: dismiss alert and show data. The new alert has 3 outcomes: hide data, show data, and dismiss alert. By providing the explicit hide data action, we prioritize the experience of new users while retaining the same set of functionalities for advanced users.

At least in theory. Now that I have explained this change in more detail, I am looking forward to your opinion on this!

As a bonus, ideally we would this kind of alert not to exist at all (given that it’s just a technical limitation of the app). After numerous optimizations we have already increased the rendering threshold from 2000 to 8000 and could probably go higher than this. Rendering lots of elements is super fast in OSM-NG compared to the current implementation.

@Dimitar155 I agree it would be more intuitive to deduplicate them. I have posted an issue which should be completed before the first public release.

@Koreller I haven’t seen that one! Thank you for letting me know, I’ll definitely take some inspiration 🙂.

Loving it

Zgodze się że w OSM brakuje dobrej metody filtrowania zmian. W dalszych planach mam zamiar dodać nową dedykowaną stronę, coś w stylu osmcha ale lepiej zintegrowaną.

There are no specific requirements. It should work as long as the crossing is visible. The data has not been trained on any specific resolution - which varies across Poland.

Yes! That’s one of the things I definitely want to see in OSM-NG :-)

@mmd exactly!

@快乐的老鼠宝宝 I don’t believe the Python will be a performance issue here - most of the heavy lifting is done by the postgres database. Also, OSM-NG uses https://cython.org to further improve performance by reducing Python interpreter overhead. 1) The demo site will be available at the end of May. Although, it won’t be feature-complete - more focussed on technical demo and development tests. 2) The export scale is not currently implemented, I wanted to simplify the share experience. The initial demo site will only consist of shortlinks. I’ll see what people have to say and go on from there.

I agree the file picker could be nicer. I’ll write it down in my notes, since I am currently focusing on reaching feature parity with the current website. About the other suggestion, that’s a good catch. I made a quick fix https://img.monicz.dev/-P5SbRuQJa4 and it looks good :-)