On Sat, Sep 12, 2009 at 2:51 PM, [email protected] < [email protected]> wrote:
> On Sat, Sep 12, 2009 at 8:37 PM, Anthony <[email protected]> wrote: > > On Sat, Sep 12, 2009 at 2:17 PM, [email protected] < > > [email protected]> wrote: > >> > >> You have this directory already! > >> Just extract all the deleted articles that are not notible. > >> you will have all the small business that got deleted. > >> > >> In fact that is the biggest pain that people face, they get deleted. > >> We need some way to keep pages from being deleted, but moved. > >> > > > > I think first there needs to be a place to move them to. OSM has come a > > long way since I first proposed Wikiteer, which was meant to be a > > combination of items of local interest which were deleted as non-notable > > plus the GIS support structure to map them. Nowadays I'm comfortable > > letting OSM manage the GIS/mapping aspect and sticking to just the > > description pages (phone numbers, addresses, websites, operating hours, > > maybe even some topic specific info like menus or admission prices or > show > > schedules). > > OSM supports address and websites. > It could store all the data in fact, it is free form. > you could have key=price-food-hambuger val=1$ if you want. > Addresses, fine. Websites, maybe (it's kind of redundant putting website= http://www.publix.com/ on every single store location). Phone numbers, I'd say no - that's too transient and not really location based in the first place. Prices, absolutely not - way too transient for a GIS. Basically you can store all the data that google local does in osm. > You could, but personally I don't think that'd be very good from a design perspective. OSM could, of course, have a separate database for this type of information, but that seems like the kind of thing that the WMF does better. I can pretty much guarantee you that Google Local doesn't put phone numbers in its GIS database under the nodes table, but puts that stuff in a separate database (or at least a separate table) and links the two databases/table together. This is especially true when it comes to relatively long freeform text descriptions, both from a perspective of performance (you want this stuff in separate tables) and editing (I don't want to use Potlatch or JOSM to update the operating hours of my local library). Does OSM maintain a persistent unique ID for every node/way? That's probably the way to do it. Also solves to some extent the copyright problem. OSM can add nodes using sources its feels comfortable with, and Wikipedia can geolocate articles using sources its comfortable with, and the two can be tied together with the OSM node's unique ID - even if the positions are a few feet different due to different sourcing. _______________________________________________ foundation-l mailing list [email protected] Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
