[OSM-talk] Voting CanVec OSM Map Features: Attributes common to all entities
Ian Dees
ian.dees at gmail.com
Fri Jun 19 23:09:02 BST 2009
In my opinion, the only data that should be imported as tags on geographic
features in the OSM database is the data in the "OSM Tags" column on the
"Buildings and structures" page. The other columns of data should not be
included as tags.
- The data in the "Canvec Feature" column is a duplicate of the code (right?
you determine the feature type based on that code)
- The geometry type column is implied by how the data is structured in OSM
- The "Attribute Value" column is a duplicate of the "attribute code"
column.
- The "Attribute Description" column does not belong in the OSM geographic
database. If you want to design a metadata database for OSM, go ahead and
stick this sort of information in there.
In general, the "metadata" that describes what the values mean should not be
stored in the same database as the geographic data. The shapefile format
does this. There is a .shp file that stores the geographic data, an .xml
file that stores the description of the attributes of that geographic data,
and a .dbf file that holds the values of the attributes for that geographic
data.
The OSM database is the geographic database and the values of attributes for
that geographic data. The description of the attributes does not belong in
the same location.
On Fri, Jun 19, 2009 at 4:19 PM, Sam Vekemans
<acrosscanadatrails at gmail.com>wrote:
> Cool :)
> (I cc'd OSGeo & NRCan, so their in the loop too.) Decisions here means a
> addition or subtraction of about a Gig or so of data.
>
> So this is why i stopped uploading. Would have been nice to have heard
> more voices from the start, lol.. or maybe i wasn't listening .. lol
>
> I'm looking back at the charts.
> http://wiki.openstreetmap.org/wiki/CanVec:_Buildings_and_structures
>
> I've added a column for each attribute which is common to all entities.
>
> http://wiki.openstreetmap.org/wiki/CanVec_OSM_Map_Features#Attributes_common_to_all_entities
>
> I've gone over each tag row to discuss each. Where we can use the talk page
> to discuss further.
>
> I set it up so that people can indicate if they 'approve' or 'dissaprove'
> of that particular row, and then id/stamp and the write why they chose that.
>
> Most of the 'pending' could be probably 'disapproved', however, i feel that
> we need to answer it more than just 'we dont like it', and the answer of the
> persentage of users is also vague.
>
> We need to ask ourselves. How do we see OpenStreetMap.org basemap look in
> 5 years from now? (OSM is still a little kid) ... kinda like Facebook.
>
> Will city planners be using OSM as the main database which lists all the
> city boundaries, and all 'official' information? ... Bus Transit planners,
> Train Schedual planners, .. etc..
> If so, then the extra tags that i included initially are needed, just as we
> would expect the city planners to post their reference numbers and lot
> numbers to represent how surveyors mark data on a map. (CanVec would not
> have included those tags if they went of value to people).
>
> Do we want the National Power grid to become the defult one that everyone
> uses? When this import is done, we WILL have the national power grid
> imported, and available. But usefull?
>
> Do we want to make the OSM database engineer friendly? If so, we need to
> include all the tags. .. and ask engeneers.. Is the osm database friendly
> to you in your field?
>
> If our goal is to become the defult map, where Google even sees our map as
> valuable and uses our database licence and shows OSM as the defult basemap,
> as more and more people recognize the value of this map (ie. where Google
> can explain to Bus Companies how to merge the data to the OSM system). ...
> then we need to step it up a notch, and allow for more tags and more
> possable usages. (imagine the complete RoadMap) ... Canada will be that by
> the end of the year) ... where then looking for more to map.
>
> Ie. a map can get made of all of the data which was acquired at a specific
> date. Or by a specific technique.
> Once OSM is able to use the altitude and accuracy information from GPS
> Tracks, this information can become more valuable.
>
> In JOSM its possable to be merging and copying item tags, perhaps expand on
> that ability?
>
> There isn't a limit of the number of tags.... provided we see it as
> 'useful'. So we here need to explain how we define 'useful' for a database
> in 5 years from now.
>
> So anyway, look forward to more discussions. Play nice :)
>
> Cheers,
> Sam Vekemans
> Across Canada Trails
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090619/6ba8112d/attachment.html>
More information about the talk
mailing list