[Talk-ca] [OSM-talk] Lake Cowichan Now loaded (more of sample 092c area)

[andrzej zaborowski]

2009/6/17 Sam Vekemans <acrosscanadatrails at gmail.com>:
> Answered below,
>
> Twitter: @Acrosscanada
> Facebook: http://www.facebook.com/sam.vekemans
>
>
> On Wed, Jun 17, 2009 at 4:57 AM, "Marc Schütz" <schuetzm at gmx.net> wrote:
>>
>> > I think the definitions really don't belong in the the data -- perhaps
>> > if you want to see them, your browser should look them up in some
>> > table rather than load from the data.
>>
>> +1
>>
>> It should be sufficient to keep the canvec:UUID, source and attribution
>> tags, and maybe a few of the other canvec:* (CMAS?). I don't see why we
>> would need most of the others. If someone is really interested in them, they
>> can look them up in Canvec using the UUID.
>
> Actually, its not that easy to look up a source with the uuid from CanVec
> data.
> They would need to open up the shp files and sift through the data.
> Unfortunately the canvec data isn't organized to that extreem on their
> website.

You don't need to look it up in the shp files, you can have it in a
huge xml file or somewhere else because it's a trivial 1:1 conversion.
 The point is that the definition of what is a school (not the
particular school to which the tag is attached) belongs in an
encyclopaedia, not in a database of geographic data.  The school
object on the map is already fully defined by "amenity=school", now,
if you want to interpret this you need to look it up in the
Map_Features page or an encyclopaedia or in 99% cases from your prior
knowledge.

>  The purpose of keeping the uuid is that it might be used during
> the conversion process to compare old/new canvec data.  Other than that, the
> "source" tag is really the only one that is technically needed.
>
>
> Arguments to keep all original tags as available.
>
> When importing large amounts of data, not only are we importing the data,
> but also opening the door to all of the users of that data, who now have a
> 2nd choice of where to extract the data (cloudmade provides shp files of OSM
> data)
> So now, users of geogratis data, can turn to OSM, where they can now see the
> value of working WITH the data. For example, a federal parks manager, who
> would turn to geogratis to get a basemap, can now use OSM, as the map is
> more accurate.
> However, because government is a stickler for 'official source' we can
> provide the source tags, that anyone can go to geogratis and varify the
> detail.
>
> This is a fair trade off, as not only am i copying the data, i am providing
> an accurate 'carbon' copy of the origional source.
>
> In order to be 'sync' with the import data, it all needs to be there. (All
> or none?)
>
> I think this is a fare tradeoff, as it lets us have are cake, eat it, AND
> also share it with more types of data users. (where a certain other map,
> doesnt do this)  ... (ie if BC Parks decides do donate their 'official'
> property boundaries) they too could include their back-end cross referencing
> system, and ALSO include osm standard tags)
>
> Arguments against:
> -This is OpenSTREETMap where we only provide ways with names, and make
> relations and add things that end users want.
>
> But, an end-user can also be a city planner who is thinking of sharing all
> there origional survay data, and property boundary information. Provided
> they can also include lot numbers, and official property easment.
>
> If there is an unlimited number of tags alloud, why not keep them?
>
> If i remove SOME and not ALL, where do we draw this line in the sand?
>
> I think we need to make it clear on a global level, exactly WHAT should be
> included or omited with an import. (any builk import for that matter)

It's quite clear, I think:
 - include things that carry some new information (e.g. amenity=school)
 - omit things that are redundant, because they can be inferred from
other tags on the object or from an external, non-geographic database
(the definition of a building, school, road)

There's a 1:1 correspondence between the value of amenity= and the
value of canvec:value_definition= so one of them should be removed.
There's a 1:1 correspondence between the value of canvec:entity= and
the value of canvec:entity_definition= so one of them should be
removed.

For example, let's say you're making a database of large prime
numbers.  For each entry you could store the prime number N, some kind
of proof of why it's a prime or a method of deriving the number, the
name of the discoverer, but not:
 - the definition of a prime number (redundant),
 - N+1 (redundant),
 - N^2 (redundant),

>
> If you dont like it because it looks like 'clutter', but infact its useful.
> .. i dont know if thats a strong argument.
>
> Perhaps I think we need to find a former Geogratis user, who will now be
> using OSM. And find out just how useful there tags are.  (as im not one, my
> voice is rather quite)
>
> Right now the evedence to keep all the tags is not that great. ...
>
> The process of removing these tags is not small.  So a definate answer
> should be found before i continue with more importing :)
>
>
>
>>
>> created_by should be removed, too. This is better moved into the
>> changeset. One could even argue that "source" belongs there, too.
>
> Well 'cause its not only me uploading, it can be anyone who wants to use the
> canvec2osm script, you dont need to be logged in with geobase:username.  ...
> because your only importing a few features that you want.  ... and there's
> no way to control what gets typed into the changeset.   Would be nice if
> everyone followed what im doing. ... but not possable.
> The created_by tag of 'canvec2osm' so people know it was my (crappy script)
> that made the mess :), so they can turn to me, and go to the canvec2osm wiki
> page to try to figure out how to fix problems.
>
>>
>> Regards, Marc
>>
>> --
>> GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss
>> für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
>
> Cheers,
> Sam Vekemans
> Across Canada Trails
>