Discussion: What should datum/projection be in US maps?

UTM WGS84? (e.g. https://epsg.io/32610) ?
UTM NAD83? (e.g. https://epsg.io/26910) ?

I think it would be great if all maps used the same projection :).

I have my feelings about the issue but why is that important to you?

For O maps it really doesn't matter afaik: The offsets between those two are well within the line thickness of the thinnest ISOM/ISSprOM symbols...

More important, probably, is the choice of UTM zone: You cannot have a zone change in the middle of your map, or if you do then you have to select one and transform all the data from other zones into this target zone.

Here in Norway we use WGS84 for everything, but UTM 32N, 33N or 35N (no 34!) depending upon how far east you are. This is effectively a north-south split since Norway lies at slant, so that we use UTM32N for everything from our south cape (Lindesnes at 58 degrees N/7 East) up to and including Trøndelag at around 65N/14E. At the county border between Trøndelag and Nordland we switch to 33N and since this is nice orienteering terrain (https://mapant.no/?#8/65.418/13.392) any map maker here has to make a choice between them.

I am guessing you will get into the same issues along the borders of all your various State Plane zones?

We are right on the border between 16T and 17T, and one large map straddles the boundary. Not a big deal, just need to be aware of that when reprojecting, and choose consistently.

I've been using WGS84 for the datum.

WGS84 and NAD83 indicate differences within UTM? Who knew? OCAD must be picking that up automatically.
I thought the concern was that in the USA there is a patchwork quilt of states some having their LiDAR done in UTM, some in State Plane, some indicating Lambert Conformal Conic. In Canada most LiDAR is UTM but Quebec is MTM.

It was once a disadvantage being a small country with no land borders. It has distinct benefits. We cross two UTM zones but use a special-purpose "NZ" TM.

@gordhun: NAD is a static copy of WGS which follows the NA continental plate as is moves, so the offset increases a bit/year, but as I said, well within the minimum 1m line thickness.

@gruver: Bergen on the west coast of Norway should have been in 31N, but if you check the official UTM maps you'll see that they made an exception so to keep all of southern Norway in 32N. NZ sounds similar.

In Europe ETRS89 (the recommended reference for European Uninon) plays the same role as NAD83, it follows the Eurasian plate. GRS80 as reference ellipsoid (not wgs84). Our maps are in TM35FIN (EPSG:3067), that's same UTM zone 35N but uses GRS80 ellipsoid and is extended both east and west to cover whole country.

I am trying to write something like a guideline and having a good reason to go either one way or another would be great.

In line with the historic law that all good battles take place at the intersection of four maps, our club maps are split between Zone 54 and Zone 55 south. No adjoining maps have different zones, so we can happily live with this situation.

@TheInvisibleLog: So you're actually located on a zone boundary? What about your source data? LiDAR/vector topo? I would probably let the LiDAR guide me into which zone to choose for a given map, as you say the most important part is to make sure that adjoining maps (ie. candidates for inclusion in a single OCAD DB), are all in the same zone.

Our maps in the immediate vicinity of Bendigo are in 55, but eight kilometres to the west of western edge of those maps we cross the boundary into zone 54. I consider us fortunate that the zone boundary is not through the town. There is a lot of flat, open paddock land between the two areas of maps in the different zones so they will never be joined. As you say, I just use what the lidar spits out. We have some maps to the south and they get within two kilometres of the zone boundary. The Ballarat club have most of their maps in 54 but some are in 55. Again, no contiguous areas.

It isn't actually that hard to handle split source data, for https://MapAnt.no/ we got our LiDAR files from 3 zones (32N, 33N and 35N), so I simply use LAStools' las2las program to convert the files which came from the "wrong" zone.

This way the entire MapAnt map is in zone 33N, with no visible boundaries, like here between Trøndelag and Nordland where the boundary passes from west to east just north of the lake with the east-pointing beak:
https://mapant.no/?lat=65.10142006397544&lng=1...

Is that the line across the big lake?

@jjcote: Probably so: All the topo data is stored per city/community, so there will be an artificial lake edge (from both sides) along the boundary. It is marked in such a way that we can elide it, and I do so in my own code, but we're not using that for the bulk operations here.
The standard Norway map is here, showing the boundary line:
https://norgeskart.no/#!?project=norgeskart&la...