Scrollable Mapview on tmtest

[michih]

-When you open the page, the first thing you see is something to enter in the lat/lon. Only after a few seconds of me looking at that and going "uhhh..." then I saw that I could enter in a city to go to. I think you should make this more prominent because nobody is going to know what lat/lon coordinates they want to start out at.

yep! I suggest moving "Find place" on top and hide the lon/lat (to be opened by "Extend").
And I like to have a button that my actual coordinates I directly loaded (well, only if the privacy settings of my device allows you to know my location)

It would be great to get any feedback that the location was found and that I need to press OK to load the map. It's confusing even after some attempts now.
edit: I realized now that there is a feedback. When the location was found, lon/lat is updated. There should be something more visible though (a check icon, OK button color change,...).

-Also, add an option to that screen to input username. It's kinda clunky to have to type that into the URL.

I reported this. It only happens when you open it from the motd link. I works when you open it from the user page. I suggest removing the link from the motd.

[yakra]

Putting the "Find place" box on top is fine.
But "Set Initial Location and Zoom Level" isn't much real estate to lose; hiding it would just serve to make things less usable: more clicking, a more convoluted interface...
If possible, maybe accept both lat & lon values in a single field, to facilitate pasting coords E.G. from popups from the HB or wptedit.

As for the functionality of OSM Nominatim itself, it thinks "Portland" is somewhere in the Pacific coast. Which we all know is factually incorrect. "Portland CT" maps to a road by that name in Great Yarmouth, Norfolk, and "Portland ME" maps to a local road in Hermosillo, Sonora. Oh what, I gawtta type out the full name theyah, Emm Eh Aye Enn Ee? That's a bit frickin' much bub.

[Jim]

-When you open the page, the first thing you see is something to enter in the lat/lon. Only after a few seconds of me looking at that and going "uhhh..." then I saw that I could enter in a city to go to. I think you should make this more prominent because nobody is going to know what lat/lon coordinates they want to start out at.

Definitely need to reorganize that.  Putting the Nominatim search field first as mentioned here and below makes a lot of sense.

-When you have the route table open, and the route table doesn't take up the whole length of the screen, you can't drag the map if you have the mouse cursor in that area.

That's been a longstanding issue with the table CSS we've been using to keep the table above the map and all of the overlays.  https://github.com/TravelMapping/Web/issues/314
Other than that, I think this is a great feature that will add a lot to this site.
[/quote]

[Jim]

The reason it's expensive (as far as I can tell) is that it needs to look at both endpoints of each of 874,000+ segments and see if either is within the visible area of the map, and that we need to join the segments with waypoints (twice) to get locations, and with clinched to get whether each segment is clinched for the traveler.

Thoughts on including beginning/end latitude/longitude directly in the segments table and eliminating the JOINs for a potential speedup?

Maybe.  Better might be to include a bounding box as an SQL GEOMETRY that would be more readily searchable.  I tried this on the waypoints table with just POINT values but it actually slowed things down.  For the smaller-sized queries, splitting out waypoint queries first then searching for segments sped things up enough that I stopped looking at the spatial functions in SQL.

[yakra]

splitting out waypoint queries first then searching for segments

Got a link to where this is done in the new code?

[Jim]

splitting out waypoint queries first then searching for segments

Got a link to where this is done in the new code?

https://github.com/TravelMapping/Web/blob/master/lib/getVisibleSegments.php

[vdeane]

One weird thing I noticed: where state or US routes cross interstates, the state or US route draws on top of the interstate.  Overlaps are handled correctly, and this doesn't happen between US and state routes, so it's a little odd.  Regular mapview like we have for the regions doesn't do this.

[yakra]

One weird thing I noticed: where state or US routes cross interstates, the state or US route draws on top of the interstate.  Overlaps are handled correctly, and this doesn't happen between US and state routes, so it's a little odd.  Regular mapview like we have for the regions doesn't do this.

Polylines do not appear to be stacked by tier.
Looking at my travels in Worcester MA, MA70 renders atop I-290.

Already noted: https://github.com/TravelMapping/Web/issues/436

[Jim]

The tmtest version for scollable Mapview now has:

- rearranged and clarified search box.
- user and units selection, stored in cookies for persistence.

I'm going to see if I can knock off the stacking order before putting this live on the main site.

[Jim]

Stacking order is good on tmtest now too.  I'm going to see if I can tackle any other scrollable Mapview problems I'm aware of before a 3:30 meeting.

[michih]

The tmtest version for scollable Mapview now has:
- rearranged and clarified search box.

Much better now! I just don't like the look. E.g. the OK button is almost invisible...

New: Reopen start position popup

[Jim]

Now live on the main site:

- rearranged and clarified search box
- user and units selection in search box
- stacking order of polylines honors tiers
- can click the map in the space below the routes table

[yakra]

- can click the map in the space below the routes table

[michih]

Does anyone else want routes 100% clinched being indicated with a different backcolor similar to how traveled segments on the HB route table are indicated?
https://github.com/TravelMapping/Web/issues/440

(or a filter to "remove" all routes 100% clinched to ease seeing untraveled segments for planning trips?)

[Markkos1992]

Does anyone else want routes 100% clinched being indicated with a different backcolor similar to how traveled segments on the HB route table are indicated?
https://github.com/TravelMapping/Web/issues/440

(or a filter to "remove" all routes 100% clinched to ease seeing untraveled segments for planning trips?)

I would support both.