more intelligent display of many waypoints
The following screenshots are from "Joes Hüttenliste" ( http://www.tourenwelt.info/commons/do... ) , a big database of many alpine huts around the planet:
I think Locus could do a better job in displaying big datasets: You would need to calculate number of "covered" pixels, ie anything on screen that is either a text label or an icon. Depending on the ratio of covered pixels vs total pixels, one could do stuff like this:
while (ratio > 30%)
{
hide_a_few labels();
turn_icons_into_simple_2x2_dots();
...
}
Fine tuning has to be done obviously to find out what works. It is important however, that this is more or less automatic, without the need for complex user interaction with a multitude of options. The only setting I can imagine is the "cover ratio". Users could tune it according to their preference (or set to 100% to disable this feature).
I think with careful programming, this could be done in a way that works nicely for most datasets and most users. Anything is better than covering the whole map with a mess of labels or icons after all.
I like this idea 
What about extending POI grouping to higher zoom levels?
What about extending POI grouping to higher zoom levels?
Enable POI grouping – for faster map plotting enables to group all visible POI on the map into individual categories in lower zoom in of map
http://docs.locusmap.eu/doku.php/manu...
Enable POI grouping – for faster map plotting enables to group all visible POI on the map into individual categories in lower zoom in of map
http://docs.locusmap.eu/doku.php/manu...
POI grouping is not the same and quite useless in this case.
POI grouping is not the same and quite useless in this case.
POI grouping is enabled in the screen shots above. Download the file and see for yourself :). And its not the same anyway and does not help in this case. There is no way around calculating the "pixel ratio" if you want to do it properly. Just doing it by number of points or zoom levels will not help.
POI grouping is enabled in the screen shots above. Download the file and see for yourself :). And its not the same anyway and does not help in this case. There is no way around calculating the "pixel ratio" if you want to do it properly. Just doing it by number of points or zoom levels will not help.
The menu items in Locus
"show labels always, show labels on hover"
are the wrong approach as well if you ask me. Why must I decide that? Why can not Locus decide that for me automatically? When there is "enough room" on screen to show me labels without messing things up, show them. If not, hide them.
It is not right to bother the user with this choice. The default should be "automatic". It mustnt matter if I click on a ten-point-gpx or a tenthousand-point-gpx, Locus should always display everything perfectly. And it could!
The menu items in Locus
"show labels always, show labels on hover"
are the wrong approach as well if you ask me. Why must I decide that? Why can not Locus decide that for me automatically? When there is "enough room" on screen to show me labels without messing things up, show them. If not, hide them.
It is not right to bother the user with this choice. The default should be "automatic". It mustnt matter if I click on a ten-point-gpx or a tenthousand-point-gpx, Locus should always display everything perfectly. And it could!
>POI grouping is enabled in the screen shots above.
>Download the file and see for yourself :).
i see...
but...
...thats stupid - sorry ;)
noboby need a list with 15.563 huts - in ONE category.
>POI grouping is enabled in the screen shots above.
>Download the file and see for yourself :).
i see...
but...
...thats stupid - sorry ;)
noboby need a list with 15.563 huts - in ONE category.
Gynta, zoom in to a larger zoom level and see yourself...
Gynta, zoom in to a larger zoom level and see yourself...
i choose zommlevel 9 - like joelocs screenshot.
which one you like?
i choose zommlevel 9 - like joelocs screenshot.
which one you like?
I don`t know, what`s wrong with that ;)
I don`t know, what`s wrong with that ;)
Anyway, this topic isn`t about POI grouping :)
Anyway, this topic isn`t about POI grouping :)
that`s true.
it`s an idea - and anybody can vote...
that`s true.
it`s an idea - and anybody can vote...
Ehm btw, Menion, can you please check changes for resolution of the maps with this huge gpx file? I think the points are not displayed correctly with different resolutions...
Ehm btw, Menion, can you please check changes for resolution of the maps with this huge gpx file? I think the points are not displayed correctly with different resolutions...
I can understand how somebody can have such needs. and to be honest, at this point we should have subcategories of points. to easily turn on only some of the areas. but to still keep the huts together in one main category. in this way, they are more maintainable.
I can understand how somebody can have such needs. and to be honest, at this point we should have subcategories of points. to easily turn on only some of the areas. but to still keep the huts together in one main category. in this way, they are more maintainable.
Stephan,
I`m not sure I completely understand ...
I`m sure you perfectly know, how precious is CPU power. Current system is simple, it just count number of labels that I need to draw. If there is more then 100, I show label "too much labels ..." and end handling with labels for that draw cycle
with changing of icons to small dots, it`s just based on current map scale, nothing more. It can be anyway simply improved.
But some, counting of coverage by icons and labels as percentage of whole screen .. ahh, is this really needed on mobile device? I personally never had problems with it. If there is too much icons on map, isn`t problem in number of icons and not the way how icons are drawn?
In all cases, I much prefer worst map readability and usage before battery consumption etc.
Stephan,
I`m not sure I completely understand ...
I`m sure you perfectly know, how precious is CPU power. Current system is simple, it just count number of labels that I need to draw. If there is more then 100, I show label "too much labels ..." and end handling with labels for that draw cycle
with changing of icons to small dots, it`s just based on current map scale, nothing more. It can be anyway simply improved.
But some, counting of coverage by icons and labels as percentage of whole screen .. ahh, is this really needed on mobile device? I personally never had problems with it. If there is too much icons on map, isn`t problem in number of icons and not the way how icons are drawn?
In all cases, I much prefer worst map readability and usage before battery consumption etc.
You prefer bad map readability and usage? Ouch :)
The problem is simply that Locus is not flexible enough to allow using point databases of varying sizes easily. I find myself constantly enabling and disabling labels and icons and show-on-hover settings, depending on what maps I use and where I zoom to and what is currently visible. That is not very convenient. At the very least, these settings must be available per category, not just globally.
But wouldnt it be much nicer if there was only ONE SINGLE setting that would work nicely in almost all cases?
Maximum Map Clutter: 10%...20%...30%...40%...50%
This is, after all, what users try to "emulate" when chosing their icons & label settings.
CPU usage? Come on... its only a few adds... most things can be pre-calculated. That cannot make any difference. The clutter value doesnt need to be pixel exact. iconsize is simply width*height and labelsize is simply strlen(label)*fontheight*textwidth("n")
while (--maxiter) // pseudocode
{
clutter = 0;
for (point:visiblepoints)
{
clutter += point.iconsizeinpixels;
clutter += point.labelsizeinpixels;
}
if (clutter <= maxmapclutter) break;
hide_the_most_distant_labels();
shrink_some_icons();
}
if its still too cluttered here, you can do POI grouping as a last restort.
As to exactly which labels are hidden and which icons are shrunk and how many, that remains to be figured out. You could obviously be fancy here and first do a 50% labelsize shrink and a 50% iconsize shrink as first step, and only then hide labels completely and replace icons with dots if its still too cluttered. There are many possibilities.
Long story short: with careful design, I believe this system could work well for almost all usage cases and make all other visibility options obsolete.
You prefer bad map readability and usage? Ouch :)
The problem is simply that Locus is not flexible enough to allow using point databases of varying sizes easily. I find myself constantly enabling and disabling labels and icons and show-on-hover settings, depending on what maps I use and where I zoom to and what is currently visible. That is not very convenient. At the very least, these settings must be available per category, not just globally.
But wouldnt it be much nicer if there was only ONE SINGLE setting that would work nicely in almost all cases?
Maximum Map Clutter: 10%...20%...30%...40%...50%
This is, after all, what users try to "emulate" when chosing their icons & label settings.
CPU usage? Come on... its only a few adds... most things can be pre-calculated. That cannot make any difference. The clutter value doesnt need to be pixel exact. iconsize is simply width*height and labelsize is simply strlen(label)*fontheight*textwidth("n")
while (--maxiter) // pseudocode
{
clutter = 0;
for (point:visiblepoints)
{
clutter += point.iconsizeinpixels;
clutter += point.labelsizeinpixels;
}
if (clutter <= maxmapclutter) break;
hide_the_most_distant_labels();
shrink_some_icons();
}
if its still too cluttered here, you can do POI grouping as a last restort.
As to exactly which labels are hidden and which icons are shrunk and how many, that remains to be figured out. You could obviously be fancy here and first do a 50% labelsize shrink and a 50% iconsize shrink as first step, and only then hide labels completely and replace icons with dots if its still too cluttered. There are many possibilities.
Long story short: with careful design, I believe this system could work well for almost all usage cases and make all other visibility options obsolete.
Concerning the point of big databases being stupid: guys... you are making the false assumption here that most people sit at home and love nothing more than creating their own databases, perfectly split up and perfectly suited for exactly their next trip. That is simply wrong, only super geeks do that :).
Everybody else just googles something like "huts gpx" or "campgrounds in france" and clicks on the gpx and thats about it. And if Locus messes it up, they will be disappointed.
Of course it would be easier if you`d find "huts-around-my-destination.gpx" instead of "allhuts.gpx" when googling, but thats not how real-life works, unfortunately.
Concerning the point of big databases being stupid: guys... you are making the false assumption here that most people sit at home and love nothing more than creating their own databases, perfectly split up and perfectly suited for exactly their next trip. That is simply wrong, only super geeks do that :).
Everybody else just googles something like "huts gpx" or "campgrounds in france" and clicks on the gpx and thats about it. And if Locus messes it up, they will be disappointed.
Of course it would be easier if you`d find "huts-around-my-destination.gpx" instead of "allhuts.gpx" when googling, but thats not how real-life works, unfortunately.
You`re right...
...provided that we are using a high end device...
You`re right...
...provided that we are using a high end device...
for (int i = 0; i < 15000; i++) {
clutter += point.iconsizeinpixels;
clutter += point.labelsizeinpixels;
}
take few precious miliseconds. This 20 times per second do quite a lot ...
1. I`ll think about it, anyway I still don`t see any clear reason for this. I have for quite a long time in mind ability to define specific settings for every category. This together with more sophisticated algorithm for POI grouping may be enough for most use cases
2. I have also inspiration in Google Earth where all is almost perfect ;)
for (int i = 0; i < 15000; i++) {
clutter += point.iconsizeinpixels;
clutter += point.labelsizeinpixels;
}
take few precious miliseconds. This 20 times per second do quite a lot ...
1. I`ll think about it, anyway I still don`t see any clear reason for this. I have for quite a long time in mind ability to define specific settings for every category. This together with more sophisticated algorithm for POI grouping may be enough for most use cases
2. I have also inspiration in Google Earth where all is almost perfect ;)
erm.. . you obviously dont sum up *all* points, but only the points currently inside screen bounds. that`s maybe a few hundred max. if there`s >1000 inside screen bounds, you can start with POI grouping right away.
google earth looks just as good as locus right now... but dont you want to be better than google :)?
erm.. . you obviously dont sum up *all* points, but only the points currently inside screen bounds. that`s maybe a few hundred max. if there`s >1000 inside screen bounds, you can start with POI grouping right away.
google earth looks just as good as locus right now... but dont you want to be better than google :)?
Hi,
Let me join this discussion. I agree with Joeloc that users don’t create own category but simple download same package of POI they found. On the other hand I think that Menion’s POI grouping function is enough (or more sophisticated grouping function)
What about setting zoom-level for showing points on map? For example will be possible to set that category cottage will be visible only in levels 15-19? I know that this doesn’t solve mentioned problem but it could help.
Hi,
Let me join this discussion. I agree with Joeloc that users don’t create own category but simple download same package of POI they found. On the other hand I think that Menion’s POI grouping function is enough (or more sophisticated grouping function)
What about setting zoom-level for showing points on map? For example will be possible to set that category cottage will be visible only in levels 15-19? I know that this doesn’t solve mentioned problem but it could help.
It could help... but it wouldnt be perfect :-).
Even if we had settings per category and different zoom levels for appearance of labels and points and whatever, we would still be forced to constantly juggle with settings to avoid clutter: You might find a good setting for category "alpine huts" and a good setting for "peaks" and a good setting for "cols" and a good setting for "via ferratas". But what if you enable all those categories at the same time?! Your screen will be messed up all over again and you`ll start re-editing your settings to make it work :-/.
I just wanted to propose an idea that might work out of the box for all possible datasets, without any additional user interaction or configuration options. We have hyper-intelligent smartphones at our disposal and yet we still trouble the poor user with decisions that could easily be automatic.
Of course this idea requires more algorithmic intelligence in Locus than simply adding more configuration options. Wether this is doable without decreasing performance or increasing battery consumption, only menion can find out.
In my ideal "map world", points and labels wouldnt just disappear/reappear/poigroup but instead dynamically grow/shrink & fade into/outof existance while i zoom in/out, always keeping the clutter level below my preferred amount no matter how many, never cover other labels, etcpp. ok... it`s a dream... :-)
It could help... but it wouldnt be perfect :-).
Even if we had settings per category and different zoom levels for appearance of labels and points and whatever, we would still be forced to constantly juggle with settings to avoid clutter: You might find a good setting for category "alpine huts" and a good setting for "peaks" and a good setting for "cols" and a good setting for "via ferratas". But what if you enable all those categories at the same time?! Your screen will be messed up all over again and you`ll start re-editing your settings to make it work :-/.
I just wanted to propose an idea that might work out of the box for all possible datasets, without any additional user interaction or configuration options. We have hyper-intelligent smartphones at our disposal and yet we still trouble the poor user with decisions that could easily be automatic.
Of course this idea requires more algorithmic intelligence in Locus than simply adding more configuration options. Wether this is doable without decreasing performance or increasing battery consumption, only menion can find out.
In my ideal "map world", points and labels wouldnt just disappear/reappear/poigroup but instead dynamically grow/shrink & fade into/outof existance while i zoom in/out, always keeping the clutter level below my preferred amount no matter how many, never cover other labels, etcpp. ok... it`s a dream... :-)
Hi, I can understand the wish for autorezizing POI icons and labels, but as a user with a not very powerfull smartphone I would prefer more the performance and low battery consumption.
Maybe this I would support: If amount of POIs to display at the current zoomlevel is larger is larger than defined (user)setting, just display small dots instead of icons and labels. I have seen that this is allready done for certain circumstances (geocaches at zoomlevel 8 and below with no grouping).
Hi, I can understand the wish for autorezizing POI icons and labels, but as a user with a not very powerfull smartphone I would prefer more the performance and low battery consumption.
Maybe this I would support: If amount of POIs to display at the current zoomlevel is larger is larger than defined (user)setting, just display small dots instead of icons and labels. I have seen that this is allready done for certain circumstances (geocaches at zoomlevel 8 and below with no grouping).
.jpg?1362309803]
.jpg?1362309803]
Replies have been locked on this page!