Talk:Geobase/NRN - OSM Map Feature

Do you really want streets to default to residential? In the TIGER data, it has loads of 'residential' roads stretching out into the countryside, miles from any residential area. Ojw 12:04, 21 December 2008 (UTC)

Another option could be a default as highway=road, IMO most of the roads in Canada are 'country roads' where you really need to look at what the posted speed limit of that road is, as that would dictate what type of road it is. As soon as a patch of farm land becomes residential, the road class would change as the road gets paved, painted and stop lights added.

There is also the consideration that a lot of the main highway roads have already been mapped, so defaulting to the lower road class would make sense. As long as the physical lines are there, the road class can easily be changed after import, when mappers are in the area.

Also, a lot of these OSM tags, are really the 'best guess'. Until the sample area gets rendered, thats really how we can visually see if the road class needs to be changed a level up or down. Unfortunately, in each province, the road class is .... slightly different. (but technically the same surface) --acrosscanadatrails 09:59, 22 December 2008 (UTC)

geobase2osm.py

The script is still in Beta Phase, once it is cleaned up, it will be made available (ref: talk-ca list) --acrosscanadatrails 22:28, 19 January 2009 (UTC)

Also, please keep the talk-ca list informed of any progress (as well as this wiki) --acrosscanadatrails 23:18, 30 January 2009 (UTC)

FAQ: Are the GeoBase roads routable?

--acrosscanadatrails 02:50, 18 June 2009 (UTC) This might need to be re-worded, and put on the main GeoBaseNRN page. Below is all my own opinion, and needs some debate.

Answer: Unfortunately, not. However, we (the OpenStreetMap Canada Community) feels that simply having the data available, where users can manually 'attach' the roads to current OSM roads, - to make them become routeable, is much better than not having the roads 'pre-placed'. ie. the roads to be imported doesn't need to be uploaded right away, they can be used as needed, with the original file stored.

So the solution is that as users are working in each area, with purpose to enhance the area by adding more features which are OSM unique, and while they are at it; Attach the imported roads to the OSM roads. And add on whatever relations are needed to improve on the road. (ie. if it's part of a network)

The alternative is not to import the missing roads for the the area your working on, but instead, to trace over them, with using actual GPS Traces to verify accuracy. (GeoBase roads have a varying accuracy, so using GPS traces is recommended, regardless).

However, the GeoBase roads also contain more detail, such as address information (for some provinces), and well as the UUID, and "is_in:" tags. Technically, it should be possible (but not yet invented) to only extract the address data, to make it compatible with the current address schema. And so, omitting the GeoBase roads in favor of the OSM roads looses this option.

Although there is the option in josm to 'paste tags' when selecting on a map feature. .. but only for 1 at a time.

Because currently, it is not possible to merge current OSM data with GeoBase data (either 1 or the other), the preference is to retain the OSM data, as it contains relations which is not available from the GeoBase data.

Once this ability happens, it would be easy to select both ways and combine the data. And thus, make the roads routable.

FAQ: Whats more important GeoBase NID or origional OSM Data?

Answer: This question comes up a bit on the talk list. Below is an attempt to clarify it.

If the purpose of wanting to attach NID's to existing OSM data is to ensure a quality import, then some facts are missing.

The RoadMatcher program, analyzes all of the ways that are in the OSM database, be it from CanVec, and older GeoBase import, or tracing by aerial photo, or tracing from GPS Traces. The 'results' file, is what is different from this OSM file to the Most current GeoBase SHP file your looking at.

Because OSM does not control the sequencing of the UUID's, and these would be changed around as OSM users work with the geometry when adding more features, its not possable to retain all the UUID's. Just like on the other hand, if GeoBase would be extracting SHP files from OSM data to be helping out the GeoBase Dataset, they do not need to retain the OSM way id's. Nor is their any reason to. Their database would never be 100% uptodate. So there is no need for the OSM community to be so concerned about the NID's and UUID's.

This is why this dataset got approved to be imported, because it falls on the right licence. We can import the data and do what we want with it. As long as we source back and say that it origionally came from GeoBase. And users can check the history of the ways and source back to the physical position, as well as have an idea where it came from.

So dealing with updates, its clear that the UUID's are not used to compare the datasets, it's only an internal reference for GeoBase's use only (not OSM's use).

We decided that wiping out the OSM database to make room for the GeoBase road network is not a good idea. So we decied not to go this route. This is because of 1 - Data accuracy, the geobase NRN as an accracy tag, where our of-the-shelf devices are more accurate. The data was acquired in a mix of fashions.

They could be almost viewed as GPS Tracks where we trace over it.

2 - OSM Relations, the GeoBase Dataset also has relations, but not the same type. Where in OSM many ways make up different routes which are physically signed. And in OSM we are free to tag what we like (as the community agrees) 3 - Data Integrity - Me (as an importer) has no right to be interfering in other peoples work without them knowing. The 'proper' and 'community accepted code' is to contact those mappers, and even meet in person, and discuss what is to be added. The goal of the community is to make the best map possable, where we learn from eachother. And if i were just to 'drop down' data overtop of what others are doing, where some of the available data is old and out-dated, those mappers below will get annoyed. So the solution is to not interfer.

We also hold true to OSM convention that the imported data does NOT need to be used,

Downside: Because of 3 (above) the downside is that its needed to manually 'attach' the ways to the imported data. In some cases, (as known already) this causes frustration, as its almost easier to hand draw the roads from scratch, than the go through with the import process.

Goal: So in conclusions, we know that the goal of the OSM project is to create the best map possable, with the best data available. Weather or not particular ways have NID's is aside from the point. Whats more important is that the roads are accuratly labeled, and connected.

For those who dont want to be manually connecting, they are free to draw in the roads manually or trace over the roads.

Address Data: For this GeoBase Import, the address data is not the focus, this is because address data availability is not consistant across the country. The address data IS however available with the canvec2osm data, and could be used there.