From silivrenion at gmail.com Mon Apr 2 00:41:54 2018 From: silivrenion at gmail.com (Angela Morley) Date: Sun, 1 Apr 2018 20:41:54 -0400 Subject: [Talk-us-massachusetts] [Max Erickson] Re: [Talk-us] 'address' tags in Massachusetts In-Reply-To: References: Message-ID: Conceptually this seems like a great idea. I was actually unaware there were address tags written like that still in MA, my mapping has been focused mostly on a specific town with none of that data input at all. Slowly but surely. +1 for standardizing address tags to addr:* tags. Angela On Thu, Mar 29, 2018 at 8:10 PM, Greg Troxel wrote: > There is a proposed mechanical edit to straighten out the address tags > from the MassGIS import into addr:subpart tags. I think this is > conceptually a great idea and have been asking about the details, as > they are always trickier than you'd think. I am curious what other MA > OSM people think, especially if one of you wants to run Max's code with > a MA extract, or something smaller. > > Greg > > > > > ---------- Forwarded message ---------- > From: Max Erickson > To: talk-us at openstreetmap.org > Cc: > Bcc: > Date: Sun, 25 Mar 2018 21:17:08 -0400 > Subject: Re: [Talk-us] 'address' tags in Massachusetts > >There is a talk-us-massachusetts@ and I think review of your proposed > >mechanical edit should include that list. > > Okay. This is pretty preliminary still, I just decided that feedback > was a good idea. Does that list overlap enough with this one that you > forwarding the message would be sufficient? > > >I suspect people would be amenable, but it would be good to publish the > >code, and the proposed files to upload, so that they can be reviewed. > > I've put the code at https://github.com/maxerickson/massadd > > I guess I should have mentioned in the earlier message that it does > some (conservative) formatting cleanup. Tidying uppercase and > expanding a small number of abbreviations. > > There's no OSM file because I don't think it is ready for upload (it's > quick enough to generate if you have curl and python3 installed). The > data at the gist does fully reflect the changes the script would > currently make. > > >Also, it certainly makes sense that there are some values that are hard > >to parse. The obvious approach is to just leave them out (and leave > >them for manual fixing or another day), but I'm not really sure exactly > >what you are proposing to do. > > At the moment if the 'address' field is not parsed without error the > script doesn't do anything with that object. There's some 'address' > fields that are parsed incorrectly (mostly they include a po box or a > unit and could be excluded by matching for those). That's part of the > not being ready. > > >As for nodes with both the old addr tag and new ones, you imply that the > >simplest way is to clean them up before a mechanical edit. But that > >implies that if they aren't fixed first, you might do something to those > >nodes, and that seems against the spirit of the mechanical edit policy, > >which involves refraining from changes that you can't basically prove > >are correct. But I don't expect you'd be doing that, so perhaps you can > >expand on what you meant. > > Yeah, it isn't implemented yet but that is what I would do, skip those > objects. > > Overall I'm not in any hurry, but the majority of the address parse > correctly and after an edit would be used by more data consumers and > show up more clearly in editors and so on. It's something like 100 > manual fixes to clear the way for about 3900 automatic splits. > > > Max > > _______________________________________________ > Talk-us mailing list > Talk-us at openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-us > > _______________________________________________ > Talk-us-massachusetts mailing list > Talk-us-massachusetts at openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-us-massachusetts > > -------------- next part -------------- An HTML attachment was scrubbed... URL: