Proposed Import of address points in Highland County, VA

Hello,
I’m proposing my plan to import address points in Highland County, VA.

I just completed the Import of Rockbrige County, VA address points.

I won’t say what’s already been said elsewhere- except here is a direct link to the data for your review on Github.

I do have one question. Is the Import catalog still used? Unless I’m missing it, it’s no longer part of the procedures of the import instructions.
-Peter

Hi Peter!

Generally, it looks really good.

  • You do have a few cases of addresses having the exact same locations:
Multiple features in same location 38.497764466, -79.54831567..................2
Multiple features in same location 38.49907918, -79.55102425...................2
Multiple features in same location 38.336382094, -79.49125459..................2
Multiple features in same location 38.320000511, -79.59865356..................2
Multiple features in same location 38.412353372, -79.58273001..................3
Multiple features in same location 38.410612702, -79.57503514..................4
Multiple features in same location 38.41266571, -79.57787268...................2
Multiple features in same location 38.409916462, -79.58681212.................12
Multiple features in same location 38.368904845, -79.6256817...................3
Multiple features in same location 38.413585318, -79.58249014..................2
Multiple features in same location 38.411199137, -79.58330035..................2
Multiple features in same location 38.303088097, -79.72461151..................2
Multiple features in same location 38.412090104, -79.58152745..................3
Multiple features in same location 38.412293995, -79.58081381..................2
Multiple features in same location 38.412780047, -79.58103719..................3
Multiple features in same location 38.412430511, -79.58129276..................5
Multiple features in same location 38.412836184, -79.5813041...................2
Multiple features in same location 38.412576001, -79.58155503..................2
Multiple features in same location 38.412587779, -79.58170484..................2
Multiple features in same location 38.413140834, -79.58230514..................9
Multiple features in same location 38.413153046, -79.58236437..................2
Multiple features in same location 38.413456706, -79.58315202..................2
Multiple features in same location 38.413505483, -79.58317251..................2

The ones I looked at were legit (e.g. apartment units). You could leave them or during the import offset them from one another so it is obvious there are multiple addresses in a single building.

  • Street name with repeated word:

‘25’ | ‘Deer Road Road’ | ‘Williamsville’ | ‘24487’

  • USPS says that McDowell is spelled Mc Dowell, but every other source seems to suggest that it is McDowell (no space). Perhaps this is just a USPS convention when a name has an internal capital letter, since their database shows city names in all caps? In any event, I think your data is probably correct.

  • I presume you are running the JOSM validator so that mapwithia finds addresses that do not match nearby roads? There was at least one of those. I think the road was wrong in the case I saw.

Mike

Thanks for reviewing!

For the addresses and apartments sharing identical location- I have mixed feelings on keeping them because my locations on the building would be arbitrary. In Rockbridge, apartments had different locations in the source data. I do agree if kept, they should not be stacked nodes.

I’d like some feedback on this.

I’ll fix the duplicate ‘Road Road’ problem, and look at source data to make sure the script didn’t mess up an abbreviation.

The source data had ‘MC DOWELL’ as well, but like you I don’t think that’s correct. I know Google isn’t a valid source but can I use them as a messenger of information? :thinking:


Street view

And yes, the JOSM mapwithai validator. Although gotta be careful, sometimes tiger import names a driveway next to the real road so the address still validates. I try to fix road names but probably make omissions. I add VGIN RCL as a layer, referencing it to make sure it matches address data for road name. If there is a discrepancy that I can’t resolve (rare) I leave them different maybe add a fixme tag. (Prior example coming to mind ‘N and W Lane’ or ‘N & W Lane’. If I can’t resolve, leave fixme tag for ground survey to see what the road sign reads)

Yes, it should be. I see that it has been taken out of the wiki. I revised it recently but don’t recall removing the catalog. The DWG does check the catalog against potential imports so please update it. We’ll need to update the wiki.

1 Like

RE: worrying about imprecise placement of addresses in the buildings: if you add them and they’re roughly right (the correct building) it’s way easier for a local mapper to adjust it to be correct than starting from scratch.

RE: Import Catalog: when new folks want to do an import, I often point them to the catalog just so they can see what techniques people are using for various imports. So there’s plenty of benefit from listing things there beyond the “letter of the law” argument.

Category:Import from the United States - OpenStreetMap Wiki is probably more comprehensive at this point.

Thanks for the input.

Re: keeping duplicate points with different unit numbers. I agree with the idea of it being easier for a future mapper to move the node to the right spot than to create one. Also if kept, all tagging will be complete and consistent (not missing zip codes, such things are hard to enter by ground mapping). I’ll plan on keeping them, spacing them over the building.

Re: Import catalog. I’ll add this import to it. That import category page is nice I haven’t seen it before, but I’m not sure how my pages made it into the list (I’m assuming either there is tags in my wiki template or someone else manually added it).

I work shift work so it’ll be a few days till I can work on this again, and fix the road names in the data.

I’ll post here after fixing the data.

1 Like

Fixed. The correct road name is ‘Deer Run’, no ‘Road’.

[examples redacted]

I added ‘fixme=yes’ and ‘note=Check node placement for duplicate’ on all rows with ‘addr:unit=*’. I did not validate to see if there are any further duplicate nodes that do not have an addr:unit tag (and now a fixme tag). I’m not sure how I would perform this validation. My thoughts are moving forward with the import, and if there are any duplicates that I miss in manual review, that I would depend on JOSM to catch duplicates prior to upload. Is this a valid approach?

Added.

modified data uploaded to Github.

edit: want to clarify- The fixme and note tags I added are intended solely for my reference during import/review to fix and remove these tags prior to upload. Although I do leave a fixme and/or note tag when needed, I’m not sure it’s appropriate to bulk add them with imports like these nodes with duplicate coordinates.

Seeing no further comment, I’ll commence with the import.

Changesets will be recorded on the wiki page.

1 Like