OpenStreetMap logo OpenStreetMap

jsmart09's Diary

Recent diary entries

2010-02-11

Posted by jsmart09 on 12 February 2010 in English.

Long story short: added VE woodland but removed it and all HD due to duplicate nodes. Took me a while to do that but learned about changesets, conflicts, validation etc.

Wrote vbscript to generate .bat file to run shp2osm jar file and generated all OSMs for 021G10. Used Sam's rules files (mostly unmodified).

Looked at the OSM attributes. Some comments to myself on whether translations are good, what's worth bringing in etc:

2010009_0 (spot height) is translated as man_made=survey_point; ele=*. I disagree with that. It is not man-made. It gets rendered with an icon showing a surveyor like a survey control point might be. Will not import. OSM does not seem very good for Z.

1460009 is rapids, good. But OSM map features does not have an approved tag it seems. ACT has proposed but it is "abandoned". Will import anyway.

1350012 is a pit, "an excavation from which gravel, sand or clay are removed." Translated as landuse:industrial. I disagree with the translation. It is not an industrial area in the sense of factories or industrial estate. Better translation would be landuse:quarry and resource=aggregate. Not sure if I will import. Could have topo significance?

1360019 is a "domestic waste" i.e. a dump. Translated as landuse:landfill. I agree.

2110009 is a lumberyard. Translated as landuse:industrial, type=lumber_yard. I disagree. type is a property and properties should describe the nature of some entity (e.g. it is "narrow" or "disused"). I think there should be a proposed feature landuse:lumberyard.

1210009 is NTS map sheet boundary. Translates as boundary:administrative which I think is wrong. There is no place for this in the OSM catalogue.

1000039 has 1000032 cemetery. Translates as landuse:cemetery. Good.

See full entry

2010-02-07

Posted by jsmart09 on 8 February 2010 in English.

021G10: converted and uploaded:
021g10_4_0_HD_1480009_1 - single line watercourse
021g10_4_0_HD_1480009_2 - waterbody areas
021g10_4_0_SS_1320049_2 - saturated soil a.k.a. wetland

Rules files used:
HD_1470009_1_Single_line_watercourseRULES.txt
HD_1480009_2_WaterbodyRULES.txt
SS_1320049_2_WetlandRULES.txt

Modified the HD_1480009_2_WaterbodyRULES.txt to uncomment the permanency translation. This allows intermittent water areas (i.e. seasonally exposed sandbanks) to be tagged as something other than plain natural:water.

I don't know the significance of the "french rules" and "outer rules" files.

Sam has added me to the list of viewers for the Google spreadsheets which detail the recommended approach to the Canvec features. I note that single line watercourse is a "don't" but I do not see why we should not add these, and I also noticed other tiles to N of London ON that have these; and very good they look too. So I think NB should have single line watercourses too!

Did a little bit of editing to clip a pre-existing bit of double-line river from 021G10, so learned a couple more JOSM commands.

There are closing lines remaining e.g. at W edge of 021G10, half way across Oromocto Lake. I think the best approach will be to put all the waterbodies in for all tiles, then do another pass to tidy up. I'll try that idea with an adjacent tile, when I have time.

Tomorrow? Maybe some "vegetation" i.e. forest.

Location: Gladstone Parish, Capital Region Rural District, Sunbury County, New Brunswick, Canada

2010-02-05

Posted by jsmart09 on 6 February 2010 in English.

Today I learned a bit about multipolygon-type relations in the OSM data model. My understanding is that a multipolyon is a relation object, and it contains one or more other objects. E.g. it could contain a lake and a couple of islands. I have skimmed through the [[Relation:multipolygon]] page.

I have looked at Sam Vekeman's rules files for HD_1480009_2_Waterbody. There are actually 3 versions of the file but they all seem pretty well the same. Essentially the rules files filter on geometry, attribute and value of the shapefile and map to an attribute and value in the OSM file.

The shp-to-osm.jar is clever because it seems to split edges (ways) up to be a 2000 node maximum which presumably is some limit for OSM datatypes for ways. It also manages to deal with SHP file outer and inner types, and it creates relation:multipolygon objects for areas that have islands.

I found myself reading an ESRI tech description of SHP files: http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf, briefly, just to get a better feel for how the outer and inner rings are done.

I ran the shp-to-osm jar on the HD_1480009_2_Waterbody SHP file. I get an .osm file out. I loaded that into Global Mapper 10 and it loads but it does not seem to know about the relations. Consequently picking on an edge just tells me attributes of that edge (and actually there are no attributes since shp-to-osm has put all the attributes on the relation).

JOSM loads the .osm and picking on an area object edge shows me that there is a relation:multipolygon object, and lets me see the members.

JOSM renders e.g. lake names using the name:en tag (if I have my preferences set to use English or default, which for me is English). Some of the waterbodies in 021G15 have names, while some waterbodies have multiple lakes and rivers massed into a single object, with no name. A cleanup phase could see me(?) go an close off lakes, give them names and remove the point toponymy names (see 2010-02-04 diary entry).

See full entry

2010-02-04

Posted by jsmart09 on 5 February 2010 in English.

Today I have looked through the Canvec documentation, which is here: http://geogratis.cgdi.gc.ca/geogratis/en/collection/28954.html

In particular, the Data Product Specifications http://ftp2.cits.rncan.gc.ca/pub/canvec/doc/CanVec_product_specifications_en.pdf

and the Feature Catalogue: http://ftp2.cits.rncan.gc.ca/pub/canvec/doc/CanVec_feature_catalogue_en.pdf

I want to understand these so that I can understand the rules files that Sam Vekemans has set up.

Incidentally Geobase or Canvec? From what I can see Geobase is an initiative, to bring in data from multiple authorities. There is a variety of types of geo data. Canvec is basically the NTS topo map data but it has been reformatted / remodelled. New editions of Canvec are brought out, apparently every 6 months. We are onto edition 4 for NB at least for Fredericton area. The actual spatial data rarely seems to change and some parts are just as out of date in the newest edition (well actually they're more out of date!).

NRN (National Road Network) has been incorporated into Canvec so there seems to be no difference in the data whether you get roads from Canvec or from NRN files.

How to figure out what SHP file some entities / objects are in? Two letter code indicates general theme e.g. HD is hydrography, TR is transportation, TO is toponymy. Within the theme, there is a 7-digit code that indicates the entity type (what I'd think of as "object class"). E.g. 1480009 is the generic code for a Waterbody. Geometry (point, line, area) is split out into separate SHP files. So we have e.g.

021g15_4_0_HD_1480009_2.shp for:

NTS tile 021G15
Edition 4
Version 0
HD for hydrography
1480009 for waterbody objects
2 for area geometry

Inside this SHP file there are all the waterbody objects for the area of 021G15.

See full entry

2010-02-03

Posted by jsmart09 on 4 February 2010 in English.

Played with Potlatch "revert" function. Bit painful since you can't step quickly through versions or see easily what has changed between versions (e.g. attribute change or spatial change, or spatial but not in the area you're zoomed in on).

Spent more time assessing accuracy. I have been using Global Mapper (GM) v10.02 which can load and display .osm, .shp, .sid. I have overlaid OSM / NRCan (Geobase / Canvec / whatever), SNB's 1:10k topo, SNB's SID orthophotos. Findings, in no particular order:

- the SIDs are quite useful, very useful since a lot of the Yahoo imagery has too coarse a resolution to resolve roads. From what I recall of the SID technical documentation, the accuracy is supposed to be fairly good, well it says "+/- 6.0 metres for well-defined features" here:
http://www.snb.ca/gdam-igec/e/2900e_1b_i.asp

More tech. information here: http://www.snb.ca/topo/assistance/ORE1999R.pdf. It says 90% of well-defined features (i.e. not covered by vegetation) must fall within 4m of their true position. Whenever I've plotted GPS positions on these images I have been comfortable with the locations. I think I am going to have faith in the accuracy of the SODB (Soft Copy Orthophoto Database), as an underlay to vector data to support assessment or even for on-screen digitizing.

Currency: imagery dates from 1996 - 2002. Obviously some roads have changed since then but most have not.

Legality of using SNB's data: see e.g. http://www.snb.ca/gdam-igec/e/2900e_1b_v_.asp?OrthoNum=45756660. From my reading, it says: "do what you like with it but don't blame us if you have problems".

- the SNB Digital Topographic Database (DTDB) has data in SHP format. This is topo data at a nominal 1:10,000 scale. Excellent stuff but perhaps more detailed than necessary. There are 1894 map sheets.

- the NRCan Geobase has data in SHP format on NAD83. I am interested in roads, especially their accuracy. I am also interested in grabbing water, forest, swamp, to supply context.

See full entry