I wanted to request that a new point be added on US 11 in NY between NY392 and NY41_E at Blodgett Mills Rd. It could be called BloMilRd or similar.
Done.
http://github.com/yakra/HighwayData/commit/abe736f65f0a27ddb540e01342d3e4075ba3e02dBy adding another point at Hoxie Gorge Rd, I was able to eliminate the 2 hidden shaping points and keep the overall number of points the same.
And the US11 & I-81 traces don't cross. Yay!
ToDo: check out the rest of the items mentioned in other posts in this thread.I have noticed some routes have a much lower volume of points than others and that does make it harder to log my travels accurately. For one of the more egregious examples, compare NY414 to nearby NY89 - the former has points almost exclusively at state route junctions, while the latter has points every few miles. I'm curious what makes the difference
https://travelmapping.net/devel/manual/includepts.php outlines what points should be included in a route. Basically, interchanges, other highways in TM, and then
other major highways.
BloMilRd arguably meets the
Connections to a nearby bridge over a large creek or medium/large river (not a small creek) large enough to noticeably restrict the number of bridges that cross it criterion
(Creek? River? Large? Medium? Small?). Since it's (I assume) needed, in it goes -- even if it's not necessary for shaping along with HoxGorRd.
After that,
shaping points are added as needed to keep the shape of the route within lateral tolerance, as Markkos1992 mentioned
above. So with NY89 being a curvier route than NY414, it gets more of these points.
Also, is there a standard for if/when points should be included when a route makes a turn or series of turns? NY 93 in Akron, NY 96 in Waterloo, and NY 31 in Clyde all have multiple turns that lack points. NY 93 in particular has 4 turns in a single segment.
These are all short, minor turns, and there's not really much ambiguity in most cases looking at the OSM tiles as to where the route goes. Adding them would start to make maps overly dense and clutter up the HB without providing much benefit for travelers, so they're left out.
The only rule is that the routes stay within lateral (within the two red lines in the WP Editor). For turns in a route, it is otherwise maintainer preference.
My take on the manual is that, beyond keeping the route trace within tolerance, this is somewhat discouraged:
If the route has sharp turns or switchbacks and adding a few more shaping points there would significantly improve the trace, consider adding a few more, but be conservative.
(Emphasis added.)
For a little historical perspective related to adding lots of points at turns, in the CHM days as the data was expanding beyond interstates, there was a lot of pressure to use as few points as possible to represent a route reasonably accurately. It seems that the size of the data was really taxing the front-end implementation and the ability of the back-end servers to handle the amount of data. TM's implementation has scaled better, and the server that houses the main site has plenty of CPU/storage/memory/network resources. However, we still try to keep routes from getting unnecessarily dense. TM routings are, after all, just approximations for the purposes of tracking travels, not for detailed navigation.
To add onto this, where TM's front end
can slow down is in mapview, and the maps on the user pages. All the points are transferred to the client machine -- as text JavaScript IIUC -- and then parsed and rendered by Leaflet. If there are a lot of points/segments in a given system/region/area being viewed, the process can get bogged down & really take a while. To that end, IMO keeping the number of points to a minimum is still good practice.
CHM OTOH didn't have the interactive maps that TM does. Instead, it generated GIFs via PHP. My memory is that these were darn quick to generate, maybe even near-instantaneous, but that memory is fading. But still, the same principle applies to some extent -- more points & more segments = more CPU juice to generate the maps. With a lot of server requests, that could add up, maybe? Wonder how much a concern that was for Tim, server-side...
