[Talk-us] Portland beering
I know I was put in charge of the next Portland beering, but I'm going to have to pass the torch...life got a bit complicated pretty much right off the bat after I took the torch, so I wasn't able to follow through on that. I'm leaving Portland in about two weeks thanks to some happy developments on the professional front, so there's pretty much no way I'm going to be able to organize it in a location that's convenient to the Portland community. Mybad! ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Registration for SOTM US open
Hi all, I'm excited to announce that we just opened registration for State Of The Map US in Portland, Oct 13-14! Head over to http://stateofthemap.us/ to register to attend. There's a $30 discount for paid-up OSM US Chapter members. That's more than the annual Chapter membership fee, so if you aren't already, become a member now! You can do that here: http://www.openstreetmap.us/membership/join/ Do you want to submit a talk or session? We're looking forward to seeing your proposals! There is a form on the SOTM US web site, and I will send out a separate email with deadlines, themes etc. in a little bit. I hope to see you all in Portland! -- martijn van exel http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] administrative boundaries and Nominatim
Serge Wroclawski writes: > On Mon, Jul 30, 2012 at 8:25 AM, Metcalf, Calvin (DOT) > wrote: >> So I'm somewhat confused about how nominatim actually works. A good example >> is the building I work in (10 park plaza Boston ma) the version of nominitum >> on the website gets the correct location on the first try (note mapquest has >> it as the 3rd result) but they have it as being > > Often what happens is that you have one of two problems, in this order: > > 1. Nodes > > 2. Incorrectly prominent areas > > Nodes are a major problem. In the case of a node area, Nominatim will > attempt to guess at how large/prominent the area is. If it's a city, > for example, it will be very lose about how far out it thinks the city > borders are. Neighborhoods, same thing, and so you get these odd > classifications. > > The solution to this is to replace nodes with polygons, period. Is it sensible to have a polygon for the boundary and also a node that locates precisely the cultural/logical center? Does Nominatim ignore the node when there is a same-named boundary? Or is there some way to have a relation for a town that has both a polygon and a center? pgpSWGfohphTR.pgp Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] administrative boundaries and Nominatim
> The solution to this is to replace nodes with polygons, period. > > Is it sensible to have a polygon for the boundary and also a node that > locates precisely the cultural/logical center? Does Nominatim ignore > the node when there is a same-named boundary? Or is there some way to > have a relation for a town that has both a polygon and a center? > http://wiki.openstreetmap.org/wiki/Relation:boundary Apparently you can add a node to the relation with role admin_centre. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] administrative boundaries and Nominatim
>> Is it sensible to have a polygon for the boundary and also a node that >> locates precisely the cultural/logical center? Does Nominatim ignore >> the node when there is a same-named boundary? Or is there some way to >> have a relation for a town that has both a polygon and a center? > > http://wiki.openstreetmap.org/wiki/Relation:boundary > > Apparently you can add a node to the relation with role admin_centre. New version of nominatim supports both admin_centre and label relation members although it will also have a go at automatically merging them even if they are not explicitly tagged. The 'label' member will be merged (name and tags), relation tags win if there is a conflict. 'admin_centre' member will be merged only if the names and 'rank' (effectively admin_level / place=*) match, but other than that same rules. In both cases the node will also be added as the centre point of the polygon - i.e. the location that the map will centre on. This is a new property in the xml and json format and will be release with the new version. While doing this people may also wish to ensure that there is a wikipedia tag [1] which is now used as a basis to calculate relative importance of admin features. Adding this makes the ordering of results far better. -- Brian [1] http://wiki.openstreetmap.org/wiki/Wikipedia ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
I was unaware of the TLID bug and the fact that TIGER has changed their data model although I kind of wondered about this because I didn't see a TLID attribute in the new TIGER shapefiles. I guess the new field is LINEARID? So yeah, that makes the tlid tag completely useless then. So, I think I'm going to submit a patch with the following tags: tiger:upload_uuid tiger:tlid tiger:source tiger:separated The one argument for keeping the separated tag was that tags with a "yes" value should be reviewed manually. But the tag will only be removed if the object is being edited which means that it may have actually been reviewed. And to me the signal to noise ratio on this tag just isn't worth it. Toby ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
