Proposed Cache County UT Edits
Posted by Xvtn on 6 June 2022 in English (English). Last updated on 8 June 2022.Here are a few edits I’m interested in making in the coming months. I’m hoping to get feedback and discussion here.
Use of Directional Prefix on Streets
The proposal here suggests a system that would change street names such as “East 200 North” to just “200 North” and moving “East” to name:prefix. This system is already in use in Salt Lake City and in my (limited) testing seems to work fine with geocoders. example
Some streets in Logan have already been changed to this format. Personally I think consistency throughout the city is more important than the tradeoffs between each way of doing things.
This change seems relatively simple to update all at once using an automated edit.
Address Import
Address data is available from UGRC, and according to the Wiki it looks like the license will work with OSM. Other than a few exceptions sprinkled here and there, the vast majority of Cache Valley does not have address tags.
Challenges
- I don’t have experience with making automated edits, but am moderately confident at scripting, so I’m confident I could figure it out especially since there are a few wiki pages describing the process others have used.
- Because of mostly hand-traced building outlines, there no doubt will be hundreds of conflicts or corner cases that will require manual review and possibly in-person survey. I’m happy to go in person to check an address in the valley, but one guy can only do so much of this. I’m not sure what system (if any) is best to queue up manual review cases and mark them as solved. Notes? fixme=* tags?
- Building outlines have not been completed in Cache Valley.
I’m open to any criticism or comment on anything discussed here, or on other edits that might need to be made to improve the map!
Edit: Additional info from community
In addition to comments on this post, here are a few other things brought up on OSM US slack:
- mvexel points out that this was also discussed on the Utah OSM wiki. So, to follow the Utah established conventions, it looks like
highway=*name=*under grid systems, the prefix should be dropped. (and presumably go toname:prefix=*). Theaddr:street=*tag on non-road features should use the full prefixed street name. - It looks like the prefix separation has been implemented in other areas using a grid system as well.
Comment from ajsorensen on 7 June 2022 at 00:21
I am not a fan of removing the N E S W name prefix. I am more a fan of adding them. If a house is marked as 13337 N 200 E currently, removing the prefix will cause issues.
Example: The address 13337 200 north could mean either 13337 East 200 North or 13337 West 200 North. At worst, you are now 26 blocks (~4 miles) away from your desired destination.
The N E S W names identify the number of city blocks, from Center Street and Main Street, to the location specified.
Comment from cschmittiey on 7 June 2022 at 00:38
I don’t really mind either way for the directional prefix as long as it’s consistent. I don’t have any experience with automated edits so I’ll leave comments on that for others
Comment from Sytys on 7 June 2022 at 01:44
Importing addresses should be done as points. They can then be manually assigned to buildings. This seems to be what was done around Ogden. It’s important for multi-address buildings.
Check out RAPiD for speedy AI assisted building placements.
Shortened street names would be better.
Comment from cschmittiey on 7 June 2022 at 01:52
After thinking about it a bit, I like the shorter road names. When I first moved to Logan the maps being East 200 North when I just knew that I wanted 200 North was confusing to me. I think it makes sense to map what’s on the ground/locals taught me to expect from signs and such, if that makes sense.
Comment from Xvtn on 7 June 2022 at 03:12
Sytys, I like the idea of importing addresses as points (since this works even if there are no building outlines at all) but, assuming the goal is to eventually have them moved to buildings, I think it would be extremely tedious to go through copy-pasting tags over and over in the areas where there is obvious 1:1 building to address match.
I bet there is a way to download a chunk of data, then click through each building/addr point, manually reviewing them while not having to move the text by hand. If that makes sense. Just click “OK/Next” over and over, and “Skip/manually review” occasionally.
Comment from Xvtn on 7 June 2022 at 03:19
Regarding street names and ajsorensen’s example, I think the full address would still be 13337 N 200 E, but the N would be contained in
name:prefix, and expand out as appropriate to render an address to the user correctly, while avoiding it when labeling the line of a road. However, I could be wrong about this. I’ll do some more experimentation with it in SLC where the roads are shown correctly according to the “ground rule” (good point cschmittiey)Comment from Sytys on 7 June 2022 at 05:01
Selecting point and building with ctrl in iD editor and pressing “c” combines the two features. Having address points separated long-term from buildings isn’t bad either as points appear in search and maps. Necessary for quadplexes, etc.
Comment from Xvtn on 7 June 2022 at 15:54
Sytys, I had no idea that shortcut existed. That makes the workflow of moving addresses to buildings seem much more quick and easy.
Comment from ajsorensen on 7 July 2022 at 02:37
If you log into Cache County’s GIS page, you will find that the cities label the roads with the N E S W prefix as well.
https://www.cachecounty.org/gis/property-/-parcel-viewer.html https://gis.cachecounty.org/Websites/Parcel%20and%20Zoning%20Viewer/
Comment from Xvtn on 5 October 2022 at 16:11
I’m hoping to start importing addresses soon - I’ve created a wiki page and a new diary entry for that import. Please leave comments, concerns or suggestions (for the address import specifically) on one of those two! Thanks!