Re: [OSM-talk] Bulk import as a data layer (like gpx currently is)
On Mar 14, 2009, at 11:31 AM, Sam Vekemans wrote: +1 for that!!! Er, no. Anything that someone might ADD to the map should be, if imported, in the same place. Otherwise, someone will fire up their editor, not see the data that already been imported, and start to add it. No better way to piss off a volunteer than to waste their time. Yes, there are problems with this approach. We need to solve them, not run away from them. We'll just create worse problems if we try to avoid solving this problem. We ALREADY have to deal with it with the TIGER import. Neither that data, nor the edits made to it, are going to be exiled from the database into this proposed bulk import data layer. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bulk import as a data layer (like gpx currently is)
Well, I thought we would have one layer per each mass import (so you can look at what was imported) - one layer for TIGER import, one layer for AND import, etc ... and the data would ge trimported both in that special layer and in ordinary layer, where everybody can edit it. In future, we can have layers even at different servers not operated by OSM (for things that are not exactly within scope of OSM map), like layers with wifi hotspots, etc ... Technically, these layers will merely redirect to another server. Martin Er, no. Anything that someone might ADD to the map should be, if imported, in the same place. Otherwise, someone will fire up their editor, not see the data that already been imported, and start to add it. No better way to piss off a volunteer than to waste their time. Yes, there are problems with this approach. We need to solve them, not run away from them. We'll just create worse problems if we try to avoid solving this problem. We ALREADY have to deal with it with the TIGER import. Neither that data, nor the edits made to it, are going to be exiled from the database into this proposed bulk import data layer. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bulk import as a data layer (like gpx currently is)
I'm not sure I wrote clearly enough, because it seems like you didn't understand what I said. Everything that someone might want to add to the map should, if imported, actually BE in the map, not in a separate database or separate layer. Every editor should show this data to a user when they go to edit. Otherwise, if there are things that are available to a map renderer but not to an editor, how will the editor know that the things are in the map already? Perhaps they could use the existing map renders as a backdrop? Then you'd end up with editors as second-class citizens to renderers, and put (BACK) in the position of needing to beg for changes. That's precisely what we want to avoid by having an editable map database. On Mar 15, 2009, at 9:37 AM, MP wrote: Well, I thought we would have one layer per each mass import (so you can look at what was imported) - one layer for TIGER import, one layer for AND import, etc ... and the data would ge trimported both in that special layer and in ordinary layer, where everybody can edit it. In future, we can have layers even at different servers not operated by OSM (for things that are not exactly within scope of OSM map), like layers with wifi hotspots, etc ... Technically, these layers will merely redirect to another server. Martin Er, no. Anything that someone might ADD to the map should be, if imported, in the same place. Otherwise, someone will fire up their editor, not see the data that already been imported, and start to add it. No better way to piss off a volunteer than to waste their time. Yes, there are problems with this approach. We need to solve them, not run away from them. We'll just create worse problems if we try to avoid solving this problem. We ALREADY have to deal with it with the TIGER import. Neither that data, nor the edits made to it, are going to be exiled from the database into this proposed bulk import data layer. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bulk import as a data layer (like gpx currently is)
On Sunday 15 March 2009 17:42:26 Russ Nelson wrote: Every editor should show this data to a user when they go to edit. Otherwise, if there are things that are available to a map renderer but not to an editor, how will the editor know that the things are in the map already? Of course the editor should show everything available, but that doesn't mean it couldn't be stored in separate databases or displayed in separate layers. It just needs smarter software. -- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bulk import as a data layer (like gpx currently is)
Of course the editor should show everything available, but that doesn't mean it couldn't be stored in separate databases or displayed in separate layers. It just needs smarter software. Maybe we could get round this by keeping it all in one database, but adding a separate tag to denote where the data come from? Anyone could use this tag to filter only the data they want, or to remove data from a particular source. I'd suggest something like source=? :-) Donald ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bulk import as a data layer (like gpx currently is)
On Mar 15, 2009, at 1:02 PM, Cartinus wrote: On Sunday 15 March 2009 17:42:26 Russ Nelson wrote: Every editor should show this data to a user when they go to edit. Otherwise, if there are things that are available to a map renderer but not to an editor, how will the editor know that the things are in the map already? Of course the editor should show everything available, but that doesn't mean it couldn't be stored in separate databases or displayed in separate layers. It just needs smarter software. Well, that's fair enough. We might want to be able to do more than our tools will let us do. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bulk import as a data layer (like gpx currently is)
On Mar 15, 2009, at 1:27 PM, Donald Allwright wrote: Maybe we could get round this by keeping it all in one database, but adding a separate tag to denote where the data come from? Anyone could use this tag to filter only the data they want, or to remove data from a particular source. I'd suggest something like source= I'd suggest instead that all bulk imports should each have their own userid. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bulk import as a data layer (like gpx currently is)
2009/3/15 Russ Nelson r...@cloudmade.com: On Mar 15, 2009, at 1:27 PM, Donald Allwright wrote: Maybe we could get round this by keeping it all in one database, but adding a separate tag to denote where the data come from? Anyone could use this tag to filter only the data they want, or to remove data from a particular source. I'd suggest something like source= I'd suggest instead that all bulk imports should each have their own userid. Even mass imports are most of the time not a fully automated process and the data is reviewed before upload. That means that 1. it's possible to screw up the job, 2. it can't be done by one person if there's a lot of data. Then, it's a good thing that the users doing the upload can be contacted and use different ids. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Bulk import as a data layer (like gpx currently is)
+1 for that!!! I could easily create and store all the canvec2osm created files on my GoogleApps website www.acrosscanadatrails.com (as well as the geobase2osm NRN data, which is already being archived on http://www.mediafire.com) I would of-course have it all in a single layer, (but better to have it as separate OSM files feeding to the same source) ... better for what? I don't know... it would solve the problem for when the new canvec/geobase DB is available (+ the UUID's will be held in safekeeping) :-) These files can be copied to a master server somewhere. (The Bulk Import o-sphere, which is just below the OSM-node-o-sphere... which is WAY above the blog-o-sphere!... and close to the GPX track-o-sphere) ... plus the map can ALSO be rendered and available to view, for when using potlatch :) So having the ability to only 'pull' a select section, to use it, select it all and 'drop' in onto the current 'osm data working layer' (... as well as the ability to 'select items which are to be uploaded' would really help.) Having your userID with the automatic reference tag added ie. canvec:Acrosscanadatrails for times when you download data. (that's covered because you now have to 'login' BEFORE you upload any new data to the server.) Also, having all the tags that are stored as reference tags also come in as the user 'pulls' the data from the Bulk Import Data Layer So then only users who have added themselves to the 'Bulk Import Data' database acess list can submit data to this, using the DATASOURCE:username tag. (and have agreed to the ODbl licence?) FYI, AFAIK, just because i edited the rules.txt file and created the canvec2osm.bat (DOS instructions file), that wouldn't necessarily mean that i am the created-works importer, i just created the tool so the creativity was in the 'linking of the data', i made the chain links to fit together, but not the entire spool of chain. ... PLUS, the tool was created acquired knowledge from others. This MAY solve the database Quagmire :-) ? Cheers, Sam Vekemans Across Canada Trails Message: 10 Date: Sat, 14 Mar 2009 20:42:34 +0800 From: Eugene Alvin Villar sea...@gmail.com Subject: Re: [OSM-talk] immutable=yes Fwd: DEC Lands To: Jukka Rahkonen jukka.rahko...@mmmtike.fi Cc: talk@openstreetmap.org Message-ID: a07a5a700903140542g20a529bfq3c7cca73d3474...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 On Sat, Mar 14, 2009 at 7:33 PM, Jukka Rahkonen jukka.rahko...@mmmtike.fiwrote: Why not to store this kind of datasets as own layers in the database? DEC data could be on its own, non-editable layer, but if there's something that people would like to edit those features could be copied or lifted to anothet, OSM layer. That would make DEC updates easier as well, they would just update the DEC layer. The same approach would suit other data of similar nature as well, like TIGER or cadastrial data. +1 Having multiple separate layers in OSM would be good for various purposes. The GPS traces layer is already one we use. Eugene / seav ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
