Submitted the following request on help.caltopo.com, but it did not get any traction there.
Adding the feature here would not help with any of the up-front lag since you'd have to first draw the high-precision snap-to line on sartopo.com, but, it would address the issues of having a too-high-precision line on the map:
snap-to suggestion for speed and utility
caver456's AvatarEDIT
caver456
Mar 23, 2021 @ 10:19 AM
Snap-to slowness has always been an issue, especially the fact that it can
make the browser unresponsive for 5 or 10 or more seconds if you start the
process of adding a line in a dense area when snap-to is initially on (e.g.
to OSM, or also to Lines if you have detailed objects such as apptracks or
snap-to'ed lines). I believe with increased use of apptracks, this type of
inadvertent-initial-snap-to-lines will become more and more of an issue.
It's surprised several of us into thinking the page needs reloading or the
LAN connection has gone dead or such.
Not just slowness, but line shape can be a concern. If the line is too
detailed / too many vertices, it can obscure the underlying map features
and lead to ambiguity: Is there a road or creek under the line? Is that
line part of the underlying basemap artwork? We make a point to use only
as many vertices as needed to convey the meaning / intent to follow a road
or drainage or such - that way the person reading the map can still see the
details of the road or drainage, and can still clearly identify it as a
road or drainage.
Is there a road? Is there a creek? Are those red lines part of the
basemap? The high-precision lines make it a bit unclear.
Without snap / with intentionally lower precision, the intent is clear,
it's quick to visually distinguish drawn data from underlying basemap (or
data overlay) artwork, and the basemap features are more visible
Maybe there's a way to fix both issues, with something like a 'precision'
setting for the snap-to functionality? It's not as simple as
sampling-every-n-feet, there would have to be some smarts behind it as you
draw (unless separate snap-to datasets were saved/generated by the server
for different precision levels, in which case nothing would need to change
on the browser-side) in order to preserve intersections, bends, corners,
etc, but, maybe this could all be done with a precision slider high/med/low
that defaults to med or low in order to avoid the
inadvertent-snap-to-lag-surprises?
Thanks for considering it.
1 Posted by caver456 on Mar 23, 2021 @ 10:26 AM
caver456's Avatar
Also, just to be clear, the main impetus for requesting this feature is that we would like to be able to get the best of both worlds: snap to a long line like a 98 mile OHV route, in order to save a lot of time spent panning and clicking, but with the mentioned benefits of lower precision.
Submitted the following request on help.caltopo.com, but it did not get any traction there.
Adding the feature here would not help with any of the up-front lag since you'd have to first draw the high-precision snap-to line on sartopo.com, but, it would address the issues of having a too-high-precision line on the map:
snap-to suggestion for speed and utility caver456's AvatarEDIT caver456 Mar 23, 2021 @ 10:19 AM
Snap-to slowness has always been an issue, especially the fact that it can make the browser unresponsive for 5 or 10 or more seconds if you start the process of adding a line in a dense area when snap-to is initially on (e.g. to OSM, or also to Lines if you have detailed objects such as apptracks or snap-to'ed lines). I believe with increased use of apptracks, this type of inadvertent-initial-snap-to-lines will become more and more of an issue. It's surprised several of us into thinking the page needs reloading or the LAN connection has gone dead or such.
Not just slowness, but line shape can be a concern. If the line is too detailed / too many vertices, it can obscure the underlying map features and lead to ambiguity: Is there a road or creek under the line? Is that line part of the underlying basemap artwork? We make a point to use only as many vertices as needed to convey the meaning / intent to follow a road or drainage or such - that way the person reading the map can still see the details of the road or drainage, and can still clearly identify it as a road or drainage.
Is there a road? Is there a creek? Are those red lines part of the basemap? The high-precision lines make it a bit unclear.
Without snap / with intentionally lower precision, the intent is clear, it's quick to visually distinguish drawn data from underlying basemap (or data overlay) artwork, and the basemap features are more visible
Maybe there's a way to fix both issues, with something like a 'precision' setting for the snap-to functionality? It's not as simple as sampling-every-n-feet, there would have to be some smarts behind it as you draw (unless separate snap-to datasets were saved/generated by the server for different precision levels, in which case nothing would need to change on the browser-side) in order to preserve intersections, bends, corners, etc, but, maybe this could all be done with a precision slider high/med/low that defaults to med or low in order to avoid the inadvertent-snap-to-lag-surprises?
Thanks for considering it.
1 Posted by caver456 on Mar 23, 2021 @ 10:26 AM
caver456's Avatar Also, just to be clear, the main impetus for requesting this feature is that we would like to be able to get the best of both worlds: snap to a long line like a 98 mile OHV route, in order to save a lot of time spent panning and clicking, but with the mentioned benefits of lower precision.