2009/7/29 Christoph Böhme <[email protected]>: > Peter Miller <[email protected]> schrieb: > >> On 27 Jul 2009, at 22:14, Christoph Böhme wrote: >> >> > Hi >> > >> > "Roger Slevin" <[email protected]> schrieb: >> > >> >> Locality Classification was added as a possible "nice to have" to >> >> the version 2 schema but it has not been populated, and no >> >> guidance has been created to indicate how this field should be >> >> used (save for a table of permitted values). There is no >> >> classification data in NPTG other than that which comes from the >> >> source - and that is only there because it could be ... I would >> >> not recommend its use as it is flaky, and offers nothing in >> >> respect of newly created locality entries in the Gazetteer. >> > >> > So, it looks like we will not have any classification information. >> > Unless we just want to import the plain names this will complicate >> > the import a bit as we have to somehow map the locations to OSM >> > place- types. >> > At the moment I am having three ideas how we could do this: >> > >> > Based on the parent relationship we could guess if a location might >> > be a suburb or village. >> > >> > Many places have wikipedia entries (even villages). If we can manage >> > to automatically look the entries up and extract the relevant >> > information (population size) from the info box we could probably >> > classify a lot of places. >> > >> > The landsat data might give us some hints about the size of places. >> > We just need to find a way to retrieve this information >> > automatically :-) >> > >> > Alternatively we could just invent a value for unclassified places >> > and wait for people to classify the places. >> > >> >> It seems that the NPTG data is less useful than it could have been >> because the the lack of classification data. We do of course also >> have access to locality names from other sources including NPE maps >> for places that are more than 50 years old and our eye-balls. > > Despite the lack of classification the NPTG data can still easily be > matched with the data already in OSM. So, while not being able to > import the whole dataset we could still add some data to existing > places if we want. The NPTG has the following to offer: > > - Administrative Area > - Atco Area Code > - NPTG District in parts of the county (do these districts have any > relation with ceremonial/administrative counties?) > - NPTG locality reference > - Alternative names (e.g. welsh names)
NaPTAN includes this too, I was going to check whether the functionality was required as we started on Welsh/Scottish regions, I can't remember the reason for not implementing it immediately other than awkwardness of the way I was parsing. > - Short names > - Qualifiers for duplicate names > > Do you think we should import any of this? Especially when taking > the NaPTAN import into acconut the Atco Area Code or NPTG locality > references might become handy, I reckon. I'm not currently handling the NPTG locality ref. If it's deemed useful, we can probably do something with it. > Talking of the NaPTAN import: The NPTG data also contains polygons for > the Plusbus Zones. This data is self-contained and can easily be > imported. They could be either imported as ways tagged with their zone > code and their name or we could create an additional relation that > holds all the bus stops which are part of the zone as well. The latter > would, of course, only be necessary if there are bus stops within the > polygon which are not part of the zone or vice versa. I tried to create a relation for plusbus zone stops from the NaPTAN data but there were simply too many - we quickly hit the OSM relation member maximum. >> Possibly we just provide NPTG data as a useful 'free' data overlay >> for creating localities in OSM in association with data from NPE but >> don't spend too long trying to do an automatic import of that data. > > I am of the same opinion. Most of the missing places in OSM are small > hamlets, villages and suburbs and it is going to be really difficult to > automatically distinguish these automatically. So, I will rather improve > the NPTG viewer a bit so that it does not display NPTG places which are > already in OSM anymore. This tool can then be used as a guide to find > umapped places. > >> You mention matching localities up with Wikipedia. I see no >> licensing issues with using data from Wikipieda as far as I am aware >> btw. Would be great to tie places up with Wikipedia and possibly also >> with woeids (http://developer.yahoo.com/geo/geoplanet/) but that >> could be something for later. > > We should keep this in mind. Although, I am not sure if it makes much > sense to add tags to OSM in a completely automated process as this > information can easily be applied when its needed. > > Cheers, > Christoph > >> >> >> Regards, >> >> >> >> Peter >> >> >> >> >> > Do you have any other ideas? >> > >> > Cheers, >> > Christoph >> > >> > _______________________________________________ >> > Talk-transit mailing list >> > [email protected] >> > http://lists.openstreetmap.org/listinfo/talk-transit >> >> >> _______________________________________________ >> Talk-transit mailing list >> [email protected] >> http://lists.openstreetmap.org/listinfo/talk-transit > > _______________________________________________ > Talk-transit mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk-transit > -- Regards, Thomas Wood (Edgemaster) _______________________________________________ Talk-transit mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-transit
