Giter Club home page Giter Club logo

Comments (8)

rinigus avatar rinigus commented on May 31, 2024

This by design and I am not going to change it, at least not at the moment.

For navigation instructions: you mean that the upcoming street name or full instruction (Turn right to ...)? When showing the street name only, in big letters, it should be faded. If full instruction is shown, its displayed on multiple lines without fading. At least, that was a design.

Direction signs are also limited. Limits on street name and direction sign are imposed to keep map visible. We have to work with a limited space and that was a way that I think gives a reasonable compromise. I think in the both cases, we should expect no translation to be used - or am I wrong?

So, unless some bug was found or you give me a great example which would make it reconsider, I will close the issue in few days.

from pure-maps.

Pohli avatar Pohli commented on May 31, 2024

I attached some screenshots:

Sometimes I'd like to read the full address of search results.
screenshotpoi
screenshotsearch2

Street number not readable
screenshotstreet1
screenshotstreet2

Street name and direction sign faded out
screenshotdirectionsign

from pure-maps.

rinigus avatar rinigus commented on May 31, 2024

Thank you for sending screenshots. Give me few days to reply...

from pure-maps.

Pohli avatar Pohli commented on May 31, 2024

Please, no hurry! Actually you are very fast in replying to comments here and in OpenRepos. :-)
I forgot to mention one thing: Even if the information shown on the direction sign seems to be complete there's still the white border missing on the right side of the sign. This is a bit irritating as one could still think there's some text missing.
screenshotdirectionsign2

from pure-maps.

rinigus avatar rinigus commented on May 31, 2024

So, let's get through the screenshots:

  1. On POI view, the addresses should be fully visible. There is no need to limit info at that layer. Issue opened #54

The rest have reasoning, possibly subjective, but there is a though behind it.

  1. While in autocomplete, idea is to show a quick glance. You can get full results when you press Enter and search for your string. By compressing the results, its possible to show many options, allowing users to select quickly, if its clear. In the shown case, you would have to make full search to decide.

3,4,5 Navigation screens. Don't forget that you also have a map showing where to go. If we print out all strings, they can easily take up full screen, through the top or through the sign.

Sign size is limited by 1/2 (bit less) of the width of the screen. Note that on this sign, you should see indicators helping you to take the correct turn. I have also limited how many indicators are shown to keep map visible (some have rather large number of lines). In your example, I would use exit number.

Sign border was also set this way to keep as much space for data as possible. You can imagine its a sign which is partially shown on the screen, with the right border area out of screen.

from pure-maps.

Pohli avatar Pohli commented on May 31, 2024
  1. On POI view, the addresses should be fully visible. There is no need to limit info at that layer. Issue opened #54

Thanks!

The rest have reasoning, possibly subjective, but there is a though behind it.

  1. While in autocomplete, idea is to show a quick glance. You can get full results when you press Enter and search for your string. By compressing the results, its possible to show many options, allowing users to select quickly, if its clear. In the shown case, you would have to make full search to decide.

Okay, but I think the full search doesn't always give the same results in the same order as in the "quick results" of the autocomplete feature. I have to check this.
So of course one quick result should only take up one line. A compromise would be to be able to activate some kind of scrolling to see the hidden text. But if you really consider to implement something like that I think it should have low priority as there are more important issues than that.

3,4,5 Navigation screens. Don't forget that you also have a map showing where to go. If we print out all strings, they can easily take up full screen, through the top or through the sign.

Okay. What do you think of scrolling, like back and forth (in the top screen, not the sign)?
I just don't like to see that there's some hidden text I don't have access to. :-)

As long as a sign is visible the Auto-center feature could be changed in a way that the centre is now between the bottom edge of the sign and the bottom of the map section. What do you think?

Sign size is limited by 1/2 (bit less) of the width of the screen. Note that on this sign, you should see indicators helping you to take the correct turn. I have also limited how many indicators are shown to keep map visible (some have rather large number of lines). In your example, I would use exit number.

In my case I think the name of the exit is more important than the exit number. That's what people in Germany look for while driving on a German autobahn. The exit number usually is shown only twice, first time on the sign in about 1000 meter distance to the junction and second time in 300 meter distance. The exit name may be repeated more often. But anyway I think the exit number should always be visible on the exit sign in Pure Maps. Maybe in other countries people pay attention mainly to the numbers.
There can be more than one place mentioned on an exit sign in Germany but usually the first one is also the name of the junction and it's enough to show this one on the exit sign in Pure Maps. Otherwise if it's an interchange of two autobahns the name of the junction has nothing to do with the directions you can go after changing the autobahn. So either the Pure Maps sign shows the name of the junction and the two directions of the crossing autobahn or only the directions.
This whole thing is not so easy, the more I think about it the more complicated it gets. :-)
And there must be a solution that works in all countries. How is it handled now, which information gets onto the sign in Pure Maps?

I noticed one more issue. The exit sign sometimes pops up very soon, like 6 km before reaching the exit. Is this intentionally or some kind of bug? I think it should appear at most 2 km before exit.

Sign border was also set this way to keep as much space for data as possible. You can imagine its a sign which is partially shown on the screen, with the right border area out of screen.

I don't think that the thin border makes much of a difference. I would draw the border if the text on the sign is complete. If not let it like it's now.

Sorry for long post.

from pure-maps.

rinigus avatar rinigus commented on May 31, 2024

Okay. What do you think of scrolling, like back and forth (in the top screen, not the sign)?
I just don't like to see that there's some hidden text I don't have access to. :-)

Quite opposed to it - we shouldn't touch and scroll the device while driving.

As long as a sign is visible the Auto-center feature could be changed in a way that the centre is now between the bottom edge of the sign and the bottom of the map section. What do you think?

Well, that's what it is when people use automatic rotation. Still, signs can easily cover large fractions of the map in no time.

If you wish to experiment, you could change the code in https://github.com/rinigus/pure-maps/blob/master/qml/NavigationSign.qml .

Exit sign is supposed to pop early, so you get time to adjust.

Data itself, is coming from https://wiki.openstreetmap.org/wiki/Relation:destination_sign , see also http://k1wiosm.github.io/checkautopista2/

I do understand your feelings. Its just I arrived to this through some testing and found it to be rather optimal on long trips. If you code, I suggest you to try to change and test.

from pure-maps.

rinigus avatar rinigus commented on May 31, 2024

Closing the issue since I stick to that design. Thank you for discussion!

from pure-maps.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.