Travel Mapping
Web Design Discussion => General Web Design Discussion => Topic started by: osu-lsu on September 14, 2018, 09:36:55 am
-
Maybe its just me, but when I attempt to view the map with entire Kentucky route system (state, US, and Interstate), my web browser wheel spins, but no images come up.
I don't want to have to go to the HB table for this state to track down routes I need to add/edit, if I can help it.
-
Maybe its just me, but when I attempt to view the map with entire Kentucky route system (state, US, and Interstate), my web browser wheel spins, but no images come up.
I don't want to have to go to the HB table for this state to track down routes I need to add/edit, if I can help it.
That's a very memory intensive map to bring up. It really depends on having a browser with lots of memory available to it, and some good hardware graphics acceleration for the Leaflet maps to use.
-
However, mapview is real muuuuuuch slower than before the last Modifikation - After moving to leaflet when it was faster than before.
The modification had less benefit but a big disadvantage in loading time IMO.
-
However, mapview is real muuuuuuch slower than before the last Modifikation - After moving to leaflet when it was faster than before.
The modification had less benefit but a big disadvantage in loading time IMO.
Do you mean the change to avoid drawing the segments on top of each other?
-
No, it was another change but I don't remember what exactly. It's something I don't use / need. If I remember correct, mapcat was happy about the feature...
-
No, it was another change but I don't remember what exactly. It's something I don't use / need. If I remember correct, mapcat was happy about the feature...
Hmm, I'm not seeing anything significant in the GitHub history for the last few months since the "draw the polylines only once" feature went live in early July.
-
I'll try to figure it out when I'm back home from traveling.
-
Thanks. Maybe there will be something I can make optional to speed things up.
-
Maybe mapcat or anyone else remembers earlier. I think it was something with routes which belong together (not concurrencies drawing).
-
Maybe mapcat or anyone else remembers earlier. I think it was something with routes which belong together (not concurrencies drawing).
Sorting routes by .csv order?
-
Yep, I think that's it (but not 100% sure). I just remember that when it went live, mapview was much slower. I didn't want to be the one complaining........
-
Yes, that could be it. I'll have to remind myself what that was all about and see if the changes can easily be made optional maybe through a QS parameter.
-
Would be great :)
-
For me, as a comparison, I will (eventually) get a map for all of Texas's routes, and there are more miles in Texas than Kentucky.
If I try to upload just state routes for Kentucky (instead of interstates/Parkways/US/States combined) it does not load for me.
Don't know if that means anything for any of you.
-
The number of segments probably means more than total miles for rendering time.
-
I think the csv order enhancement slowed the SQL query time for large maps.
For what it's worth, I can load up http://travelmapping.net/user/mapview.php?units=miles&u=osu_lsu&rg=KY and get a very usable map in about 77 seconds. So that leads me to believe it's not the SQL query, which is a server-side cost, but the client-side browser resources (RAM, hardware graphics acceleration) that causes the failure for the OP. For me, this is on a 2016 Mac Book Pro, latest Firefox, 16 GB memory.
-
For me, as a comparison, I will (eventually) get a map for all of Texas's routes, and there are more miles in Texas than Kentucky.
If I try to upload just state routes for Kentucky (instead of interstates/Parkways/US/States combined) it does not load for me.
Don't know if that means anything for any of you.
The number of segments probably means more than total miles for rendering time.
A better quick-n-ditry indicator of number of waypoints, and thus number of segments, would be the total filesize of all WPTs in the region. I have 1.3 MB for TX, and 1.6 MB for KY. So KY is "bigger" but still in the same ballpark.
I think the csv order enhancement slowed the SQL query time for large maps.
"draw the polylines only once" feature thread (http://forum.travelmapping.net/index.php?topic=2514). I forget the exact fix here -- was it removing/erasing the lower-tiered polylines before drawing the higher-tiered polylines over top?
Though, it seems the CSV ordering feature may be the bigger hit...
For what it's worth, I can load up http://travelmapping.net/user/mapview.php?units=miles&u=osu_lsu&rg=KY and get a very usable map in about 77 seconds. So that leads me to believe it's not the SQL query, which is a server-side cost, but the client-side browser resources (RAM, hardware graphics acceleration) that causes the failure for the OP. For me, this is on a 2016 Mac Book Pro, latest Firefox, 16 GB memory.
About exactly my experience here. A usable map in 77 s. The first 73 seconds were just my browser waiting for the server-side magic to happen; after that I saw my network usage spike, shortly followed by the table and map rendering. Once loaded, I can zoom and pan easily with almost no lag. UbuntuMate 16.04 + Firefox 62.0 (which AFAIK isn't especially hardware-acceleration friendly?). RAM usage went from 1.1 GB before loading my mapview to 1.3 GB after.