On 13 Jul 2010, at 6:34 , Ian Dees wrote: > > > On Tue, Jul 13, 2010 at 7:39 AM, McGuire, Matthew > <matt.mcgu...@metc.state.mn.us> wrote: > > > For example: > - The proposal requires unique, persistent IDs for landmarks/points of > interest. OSM does not have an accepted way of storing persistent IDs.
there is a wikipedia project trying to achieve this. As far as I understand they try to do some local search and pattern match of tags. But there is no way to get persistent ID. A POI node can be changed to to a way or relation whenever better knowledge allows to do this. > - Addressing information (even if it is address ranges) is a necessity. > Anything we can do to make entering address information easier and more > interesting would increase the usefulness of OSM for a much wider range of > people. this is a lot of work and given that Tiger offers address interpolation already there is not so much incentive to do this. building an address DB based on Tiger provides a consistent quality but anything in osm will vary widely. In the long term individual address data will be useful for osm. But this is a huge project and will need 10-100x more active mappers at least. some counties or cities may provide such data. Then we can for sure import it. > - Updates and changes that are accepted into and created from the dataset > need to be stored somehow in a "status database". This sounds a lot like our > history page, but the history page is full of changesets that don't have > changes in the region. As has been discussed before, a tool to view a "real" > history for an area would be useful. should be easy to implement by parsing minutely/hourly diffs. the history page requires queries to the main DB and if someone starts to do heavy access they might get blocked by the admins > > Having said that, does anyone want to work with me on a proposal, even if it > only ends up giving us feedback on our data from a "real" external group? > the way osm works is so different that this doesn't make much sense. a DB where anyone at any time can modify, delete data will require constant tracking for which they will definitely need their own db. So why even bother with osm at all. using the osm toolchain is an option which can make sense. then all kinds of extensions like limited access for can be implemented. > _______________________________________________ > Talk-us mailing list > Talk-us@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-us _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
