Re: [Talk-ca] Canvec/Geobase point feature - Render

[Sam Vekemans]

Cool, i put the 'building=yes' back in service for both the 'unknown'
and 'other' feature point types.

Good thing too; as i had a challenge trying to get the 'exclusion
script' to work.

And yup, i'll subscribe to that talk list (i'll try to keep quiet on
that one) :-)

cheers,
Sam

On 3/23/09, Richard Weait  wrote:
> On Mon, 2009-03-23 at 20:05 -0400, Michel Gilbert wrote:
>> 2009/3/23 Sam Vekemans 
>>
>> I have not yet received the answer from NRCan about if the
>> location of the node is EXACTLY where the building actually
>> is, or is it just shown in the general area.  If it is the
>> former, then this information can be taken into account.
>
> Sam, why should the building point location be EXACT?  We know that all
> data, regardless of source, will have a degree of precision depending on
> many things.  Buildings are worth having, in my opinion, even if only as
> a point.
>
>> The position of buildings may be "exact" if the acquisition methods
>> was from stereo-digitization. If it came from map scanning they may
>> have been displaced for map representation purposes. My guess is 80%
>> of the buildings in CanVec come from map scanning.
>
>> What i can do, and i presume that you all would agree, is to
>> add this feature to the "not4osm" folder so then it could be
>> used as an assistant for the person who is actually uploading
>> the information.
>
> I disagree.  Worth including in my opinion.  Default renders may chose
> to render them or not.  Some future render may do "cool things" based on
> the number of buildings / area.  Who can predict future creativity?  The
> buildings exist, or existed at the time of survey.  Worth knowing.
>
>> Following the new information I received from
>> tilesath...@openstreetmap.org (i have just forwarded the email to
>> talk-ca) we may still want them for mapping purposes.
>
>>
>> We can list them, then check with the tilesath...@openstreetmap.org
>> talk if they are part of the render feature.
>
> And even if the default renderers don't want point buildings, perhaps
> the renderer at openstreetmap.ca will.  Or YourCompany.com might make a
> fortune offering point-building renderers.
>
>> For example, when the feature lists 9 or so different feature
>> types, the general practice for both GeoBase & CanVec is to
>> state "-1" unknown  and "0" none ... i would suggest that
>> these features be omitted from the import also.
>>
>> Any thoughts on that?
>
> Sam, I'm sure I don't know to what you refer here.  Could you clarify
> please?
>
>> Again it depends if the tilesath...@openstreetmap.org talk confirm
>> that no render is possible. If we really want them display we can ask
>> them ?
>
> Even if the default mapnik, t...@h and others don't render point-buildings
> we can adjust them for our own purposes.  (We can also ask the
> maintainers to add support for point buildings.)
>
> Best regards,
> Richard
>
>

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec/Geobase point feature - Render

[Sam Vekemans]

Cool, i put the 'building=yes' back in service for both the 'unknown'
and 'other' feature point types.

Good thing too; as i had a challenge trying to get the 'exclusion
script' to work.

And yup, i'll subscribe to that talk list (i'll try to keep quiet on
that one) :-)

cheers,
Sam

On 3/23/09, Richard Weait  wrote:
> On Mon, 2009-03-23 at 20:05 -0400, Michel Gilbert wrote:
>> 2009/3/23 Sam Vekemans 
>>
>> I have not yet received the answer from NRCan about if the
>> location of the node is EXACTLY where the building actually
>> is, or is it just shown in the general area.  If it is the
>> former, then this information can be taken into account.
>
> Sam, why should the building point location be EXACT?  We know that all
> data, regardless of source, will have a degree of precision depending on
> many things.  Buildings are worth having, in my opinion, even if only as
> a point.
>
>> The position of buildings may be "exact" if the acquisition methods
>> was from stereo-digitization. If it came from map scanning they may
>> have been displaced for map representation purposes. My guess is 80%
>> of the buildings in CanVec come from map scanning.
>
>> What i can do, and i presume that you all would agree, is to
>> add this feature to the "not4osm" folder so then it could be
>> used as an assistant for the person who is actually uploading
>> the information.
>
> I disagree.  Worth including in my opinion.  Default renders may chose
> to render them or not.  Some future render may do "cool things" based on
> the number of buildings / area.  Who can predict future creativity?  The
> buildings exist, or existed at the time of survey.  Worth knowing.
>
>> Following the new information I received from
>> tilesath...@openstreetmap.org (i have just forwarded the email to
>> talk-ca) we may still want them for mapping purposes.
>
>>
>> We can list them, then check with the tilesath...@openstreetmap.org
>> talk if they are part of the render feature.
>
> And even if the default renderers don't want point buildings, perhaps
> the renderer at openstreetmap.ca will.  Or YourCompany.com might make a
> fortune offering point-building renderers.
>
>> For example, when the feature lists 9 or so different feature
>> types, the general practice for both GeoBase & CanVec is to
>> state "-1" unknown  and "0" none ... i would suggest that
>> these features be omitted from the import also.
>>
>> Any thoughts on that?
>
> Sam, I'm sure I don't know to what you refer here.  Could you clarify
> please?
>
>> Again it depends if the tilesath...@openstreetmap.org talk confirm
>> that no render is possible. If we really want them display we can ask
>> them ?
>
> Even if the default mapnik, t...@h and others don't render point-buildings
> we can adjust them for our own purposes.  (We can also ask the
> maintainers to add support for point buildings.)
>
> Best regards,
> Richard
>
>

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec/Geobase point feature - Render

[Sam Vekemans]

Cool, i put the 'building=yes' back in service for both the 'unknown'
and 'other' feature point types.

Good thing too; as i had a challenge trying to get the 'exclusion
script' to work.

And yup, i'll subscribe to that talk list (i'll try to keep quiet on
that one) :-)

cheers,
Sam

On 3/23/09, Richard Weait  wrote:
> On Mon, 2009-03-23 at 20:05 -0400, Michel Gilbert wrote:
>> 2009/3/23 Sam Vekemans 
>>
>> I have not yet received the answer from NRCan about if the
>> location of the node is EXACTLY where the building actually
>> is, or is it just shown in the general area.  If it is the
>> former, then this information can be taken into account.
>
> Sam, why should the building point location be EXACT?  We know that all
> data, regardless of source, will have a degree of precision depending on
> many things.  Buildings are worth having, in my opinion, even if only as
> a point.
>
>> The position of buildings may be "exact" if the acquisition methods
>> was from stereo-digitization. If it came from map scanning they may
>> have been displaced for map representation purposes. My guess is 80%
>> of the buildings in CanVec come from map scanning.
>
>> What i can do, and i presume that you all would agree, is to
>> add this feature to the "not4osm" folder so then it could be
>> used as an assistant for the person who is actually uploading
>> the information.
>
> I disagree.  Worth including in my opinion.  Default renders may chose
> to render them or not.  Some future render may do "cool things" based on
> the number of buildings / area.  Who can predict future creativity?  The
> buildings exist, or existed at the time of survey.  Worth knowing.
>
>> Following the new information I received from
>> tilesath...@openstreetmap.org (i have just forwarded the email to
>> talk-ca) we may still want them for mapping purposes.
>
>>
>> We can list them, then check with the tilesath...@openstreetmap.org
>> talk if they are part of the render feature.
>
> And even if the default renderers don't want point buildings, perhaps
> the renderer at openstreetmap.ca will.  Or YourCompany.com might make a
> fortune offering point-building renderers.
>
>> For example, when the feature lists 9 or so different feature
>> types, the general practice for both GeoBase & CanVec is to
>> state "-1" unknown  and "0" none ... i would suggest that
>> these features be omitted from the import also.
>>
>> Any thoughts on that?
>
> Sam, I'm sure I don't know to what you refer here.  Could you clarify
> please?
>
>> Again it depends if the tilesath...@openstreetmap.org talk confirm
>> that no render is possible. If we really want them display we can ask
>> them ?
>
> Even if the default mapnik, t...@h and others don't render point-buildings
> we can adjust them for our own purposes.  (We can also ask the
> maintainers to add support for point buildings.)
>
> Best regards,
> Richard
>
>

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Address ranges

[Richard Weait]

On Mon, 2009-03-23 at 19:55 -0400, Bob Jonkman wrote:
> On 22 Mar 2009 at 12:02 Steve Singer  wrote
> about "Re: [Talk-ca] Address ranges[...]"
> 
> >Part of me prefers a scheme that adds address tags directly to the nodes
> >that make up the road.
> >
> >The downside of that is[...]
> 
> Another downside is that it doesn't reflect reality (or, rather, it 
> reflects reality even less than an arbitrary offset).
> 
> I'd rather see generated nodes (as per Richard Weait's suggestion) 
> with additional "addr" tags, eg.
> 
> building=yes
> addr:housenumber=123
> addr:type=generated-blockface
> addr:offsetlat=0.3
> addr:offsetlon=-0.1
> addr:offsetnodeid=
> 
> 
> This would be an indication that it's a suitable candidate for 
> replacement with observed data.  If the associated road node is moved, 
> the building node doesn't necessarily have to be moved, but could be 
> re-calculated (which opens its own can of worms).

Are you combining two address data issues?  

For block face addressing, we need to interpolate building location.
That was when the arbitrary offset was suggested.  I believe we have _in
other locations_ building point locations.  Are there addresses
associated with those building points?  If so, no interpolation
required.  

Also, Karlsruhe schema explicitly allows addr:housenumber as a node OR
polygon.  So no need to fake the polygons to comply with the schema.  I
believe that the sample image shows two point-buildings "6" and "4" on
the north side of Bochumer Straße?   


> One problem is that not all addresses are necessarily buildings.  
> Sometimes a park, public square or empty lot has an address.  And all 
> buildings aren't necessarily houses, so I'm not sure that 
> "housenumber" is the most appropriate tag name.

But it is what we have for the schema.  The discussion suggests that we
can make suggestions.
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/House_numbers/Karlsruhe_Schema

> When I worked at the City of Toronto and had access to their Central 
> Property Register database there were different concepts of municipal 
> addresses, postal delivery addresses, and courtesy addresses.  I 
> expect that GeoBase captures the municipal addresses. 

Which is the one that is easiest to detect when walking past the
building?  Municipal?  

> Also, I'm in favour of generating a small polygon (square) rather than 
> a single node.  This fixes Michel Gilbert's rendering problem, and 
> also more closely reflects reality.

I respectfully disagree.  And I hope that adding addr:housenumber will
work as per my guess above.  

Some have said that we shouldn't tag for the renderer.  And then others
have said that and still done amazing work by tagging for the renderer.
http://weait.com/content/science-fair-cern

Adding a fake polygon may also subtly discourage mappers from going and
mapping the buildings.  "Look at those cute, even, rectangular
buildings.  Obviously I don't need to fix that with aerial images..."  

Kind of like hacking css for a month to make it work with IE5.  Wasted
effort; bad for the psyche.  Design for the standard and you are certain
to work with the browsers of the future (renderers of the future).  

My thoughts, while my tiles render.  ;-)

Best regards,
Richard


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec/Geobase point feature - Render

[Richard Weait]

On Mon, 2009-03-23 at 20:05 -0400, Michel Gilbert wrote:
> 2009/3/23 Sam Vekemans 
> 
> I have not yet received the answer from NRCan about if the
> location of the node is EXACTLY where the building actually
> is, or is it just shown in the general area.  If it is the
> former, then this information can be taken into account.

Sam, why should the building point location be EXACT?  We know that all
data, regardless of source, will have a degree of precision depending on
many things.  Buildings are worth having, in my opinion, even if only as
a point.  

> The position of buildings may be "exact" if the acquisition methods
> was from stereo-digitization. If it came from map scanning they may
> have been displaced for map representation purposes. My guess is 80%
> of the buildings in CanVec come from map scanning.   

> What i can do, and i presume that you all would agree, is to
> add this feature to the "not4osm" folder so then it could be
> used as an assistant for the person who is actually uploading
> the information.

I disagree.  Worth including in my opinion.  Default renders may chose
to render them or not.  Some future render may do "cool things" based on
the number of buildings / area.  Who can predict future creativity?  The
buildings exist, or existed at the time of survey.  Worth knowing.  

> Following the new information I received from
> tilesath...@openstreetmap.org (i have just forwarded the email to
> talk-ca) we may still want them for mapping purposes.

> 
> We can list them, then check with the tilesath...@openstreetmap.org
> talk if they are part of the render feature.

And even if the default renderers don't want point buildings, perhaps
the renderer at openstreetmap.ca will.  Or YourCompany.com might make a
fortune offering point-building renderers.  

> For example, when the feature lists 9 or so different feature
> types, the general practice for both GeoBase & CanVec is to
> state "-1" unknown  and "0" none ... i would suggest that
> these features be omitted from the import also.
> 
> Any thoughts on that?

Sam, I'm sure I don't know to what you refer here.  Could you clarify
please?  

> Again it depends if the tilesath...@openstreetmap.org talk confirm
> that no render is possible. If we really want them display we can ask
> them ?

Even if the default mapnik, t...@h and others don't render point-buildings
we can adjust them for our own purposes.  (We can also ask the
maintainers to add support for point buildings.)

Best regards,
Richard


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec/Geobase point feature - Render

[Michel Gilbert]

2009/3/23 Sam Vekemans 

> Thanks,
> Good call. :-)
>
> The point feature "building=yes"  otherwise known as
>
> point,CODE,2010010,canvec:CODE,2010010
> point,CODE,2010010,building,yes
>
> What it does is show up as a little house icon with JOSM
>
> for the polygons, they show up as nice shapes.. and when clicked on would
> simply state this this is a building.
>
> outer,CODE,2010012,canvec:CODE,2010012
> outer,CODE,2010012,building,yes
> inner,CODE,2010012,canvec:CODE,2010012
> inner,CODE,2010012,building,yes
>
>
> I have not yet received the answer from NRCan about if the location of the
> node is EXACTLY where the building actually is, or is it just shown in the
> general area.  If it is the former, then this information can be taken into
> account.
>

The position of buildings may be "exact" if the acquisition methods was from
stereo-digitization. If it came from map scanning they may have been
displaced for map representation purposes. My guess is 80% of the buildings
in CanVec come from map scanning.

>
> What i can do, and i presume that you all would agree, is to add this
> feature to the "not4osm" folder so then it could be used as an assistant for
> the person who is actually uploading the information.
>
> However,  I would also agree that adding this feature would be similar to
> me using the Aerial imagery and whereever i spot some "THING" that looks
> like a building, quickly tag it as building=yes.  ... this information is
> meaningless to the map user.  ... odds are, that right next to it is some
> other 'building'.   Unless the purpose is clearly stated, we dont need to
> include this feature.
>

Following the new information I received from
tilesath...@openstreetmap.org(i have just forwarded the email to
talk-ca) we may still want them for
mapping purposes.

>
> And YES, there are other point features which need to be looked at to see
> if they are actually useful.  As im going through the sharts, i'll now be
> looking at it.
>

We can list them, then check with the tilesath...@openstreetmap.org talk if
they are part of the render feature.


>
> For example, when the feature lists 9 or so different feature types, the
> general practice for both GeoBase & CanVec is to state "-1" unknown  and "0"
> none ... i would suggest that these features be omitted from the import
> also.
>
> Any thoughts on that?
>

Again it depends if the tilesath...@openstreetmap.org talk confirm that no
render is possible. If we really want them display we can ask them ?

Michel

>
> Cheers,
> Sam
>
> P.S. I was thinking of adding another column to the 11 themes of CanVec
> charts, for "status"
> PPS. I am still finding some features that were accidentally missed when i
> was copying the data from the feature catelogue to the charts, so it's a
> good idea to cross-check with the .pdf catelogue to find out what the actual
> definition was. ~ probably 95% accurate, but always good to check :-)
>
> Hi all,
>>
>
>> Two weeks ago, I worked on the import of CanVec-Buildings using Map
>> feature
>>
> table on the wiki. I noticed at that time that point buildings imported as
>>
> building="yes" did not appear on the osm map. Sam probably rebembered the
>>
> discussion about it. So, I sent my question to the
>>
> tilesath...@openstreetmap.org. It appears that building="yes" will be
>>  
>
> rendered on the map only if they are polygons.
>>  
>
>
>> To conclude, I think there is no reason to import Canvec point building
>>
> unless they have specific functions. It may be true for other point
>>
> features. We should make sure before importing them.
>>
>
>> cheers,
>>
>
>> Michel
>>
>


-- 
Michel Gilbert
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Address ranges

[Bob Jonkman]

On 22 Mar 2009 at 12:02 Steve Singer  wrote
about "Re: [Talk-ca] Address ranges[...]"

>Part of me prefers a scheme that adds address tags directly to the nodes
>that make up the road.
>
>The downside of that is[...]

Another downside is that it doesn't reflect reality (or, rather, it 
reflects reality even less than an arbitrary offset).

I'd rather see generated nodes (as per Richard Weait's suggestion) 
with additional "addr" tags, eg.

building=yes
addr:housenumber=123
addr:type=generated-blockface
addr:offsetlat=0.3
addr:offsetlon=-0.1
addr:offsetnodeid=


This would be an indication that it's a suitable candidate for 
replacement with observed data.  If the associated road node is moved, 
the building node doesn't necessarily have to be moved, but could be 
re-calculated (which opens its own can of worms).

One problem is that not all addresses are necessarily buildings.  
Sometimes a park, public square or empty lot has an address.  And all 
buildings aren't necessarily houses, so I'm not sure that 
"housenumber" is the most appropriate tag name.

When I worked at the City of Toronto and had access to their Central 
Property Register database there were different concepts of municipal 
addresses, postal delivery addresses, and courtesy addresses.  I 
expect that GeoBase captures the municipal addresses. 

Also, I'm in favour of generating a small polygon (square) rather than 
a single node.  This fixes Michel Gilbert's rendering problem, and 
also more closely reflects reality. Every building I've been to has 
been more than one-dimensional :-)  Yes, this quadruples the number of 
nodes for house number polygons, but that will also be the case when 
we get around to collecting building data and mapping the building 
outline.  Of course, generating polygons makes interpolation more 
difficult...

--Bob.


-- -- -- --
Bob Jonkman  http://sobac.com/sobac/
SOBAC Microcomputer Services  Voice: +1-519-669-0388
6 James Street, Elmira ON  Canada  N3B 1L5  Cel: +1-519-635-9413
Software   ---   Office & Business Automation   ---   Consulting





___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Fwd: [Tilesathome] Building rendered

[Michel Gilbert]

Hi all,

Following the talk I started yesterday on the talk-ca I received new
development regarding point buildings not shown on the map. It seems that it
may be displayed in the future. May be we should keep them as
building="yes". What do you think ?

Michel

-- Forwarded message --
From: Knut Arne Bjørndal >
Date: 2009/3/23
Subject: Re: [Tilesathome] Building rendered
To: tilesath...@openstreetmap.org


On Mon, Mar 23, 2009 at 10:40:39AM +1100, Yoda wrote:
> building="yes" only applies to areas not a node.

Hm, we should have a rendering for that. Perhaps simply a small square
in the same style as building outlines?

I filed http://trac.openstreetmap.org/ticket/1667, anybody care to
take a crack at it?

--
Knut Arne Bjørndal
aka Bob Kåre
bob+...@cakebox.net 
bobk...@irc

___
Tilesathome mailing list
tilesath...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tilesathome




-- 
Michel Gilbert


smime.p7s
Description: S/MIME cryptographic signature
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] An exploration of the possibility of an OSM - GeoBase partnership

[Richard Weait]

On Mon, 2009-03-23 at 16:25 -0400, Mepham, Michael wrote:
> At the last GeoBase Steering Committee meeting we discussed ideas on
> how GeoBase and Open StreetMap could work together to each others
> advantage.  We believe that each group has its strengths and that by
> supporting each other we can both benefit.

Dear Michael,

I have passed your email along to the OpenStreetMap Foundation for
consideration by the board of directors.  

I know that I have enjoyed watching the discussion and progress of the
OpenStreetMap contributors with the GeoBase data.  I'm intrigued by the
idea of collaboration between OSM contributors and GeoBase in
maintenance of the road network data.  I'm also certain that your email
will set off a fascinating discussion of the possibilities.  

I've also noticed many contributions by people with nrcan email and / or
nrcan background in the discussion and progress of the GeoBase
conversion and import.  It is wonderful to have so many of you as fellow
OpenStreetMap contributors.  

Best regards,
Richard


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] An exploration of the possibility of an OSM - GeoBase partnership

[Mepham, Michael]

At the last GeoBase Steering Committee meeting we discussed ideas on how
GeoBase and Open StreetMap could work together to each others advantage.
We believe that each group has its strengths and that by supporting each
other we can both benefit.

 

Now that it appears that the import of the GeoBase data into OSM is
progressing well we would like to discuss the possibility of OSM helping
with the maintenance of the GeoBase road network.  As you are well aware
there are a lot of roads in the GeoBase data base.  The maintenance of
these roads is a significant undertaking that is being performed by all
the provinces and many of the municipalities, as well.  Probably the
most difficult part of any mapping maintenance program is the detection
of the errors and changes that need to be reflected in the data base.  

 

We think that the members of OSM are in a position to assist in the
change detection for the road network and would like to get a feel for
their interest in contributing change notices to GeoBase.  These change
notices would potentially be used in a couple of ways.  They could be
redistributed through GeoBase to inform all other users that there has
been changes detected and what those changes are.  The second use would
be to identify where our mapping crews and contractors should direct
their attention in updating the NRN as part of the ongoing maintenance
program.

 

I have posted this to the talk-ca list to initiate a discussion between
the OSM members and GeoBase.  I invite interested persons to write me
directly or through the list with any comments or questions.  I also
accept calls at the phone numbers below if you would prefer a verbal
conversation.

 

I will take the results of this conversation to the next meeting of the
steering committee in mid-April and then we, GeoBase and OSM, can work
out how (and if) to proceed.

 

Also, for clarity - Whether or not we all proceed with this idea will
have absolutely no impact on the availability of the GeoBase data to
OSM.  Access will continue on the free and unrestricted use plan as
identified in the GeoBase license in either case.

 

I look forward to your replies.

 

 

Mike Mepham

Federal/Provincial/Territorial Liaison

GeoConnections Program

Natural Resources Canada

 

E-Mail:  mmep...@nrcan.gc.ca   




 

Ottawa

Regina

Phone:

(613) 992-8549

(306) 780-3634

Fax:

(613) 947-2410

(306) 780-5191

Address:

06Ath Floor, Room. 646R 

615 Booth Street

Ottawa, ON Canada  K1A 0E9

100 Central Park Place

2208 Scarth Street

Regina, SK Canada  S4P 2J6

 

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec/Geobase point feature - Render

[Sam Vekemans]

oops,
point,CODE,2010250,canvec:CODE,2010250
point,CODE,2010250,building,yes

Indicating building=other  would also be omited, fixing up the script and
the wiki now, to see how it likes it.

Sam

On Mon, Mar 23, 2009 at 11:33 AM, Sam Vekemans  wrote:

> Thanks,
> Good call. :-)
>
> The point feature "building=yes"  otherwise known as
>
> point,CODE,2010010,canvec:CODE,2010010
> point,CODE,2010010,building,yes
>
> What it does is show up as a little house icon with JOSM
>
> for the polygons, they show up as nice shapes.. and when clicked on would
> simply state this this is a building.
>
> outer,CODE,2010012,canvec:CODE,2010012
> outer,CODE,2010012,building,yes
> inner,CODE,2010012,canvec:CODE,2010012
> inner,CODE,2010012,building,yes
>
>
> I have not yet received the answer from NRCan about if the location of the
> node is EXACTLY where the building actually is, or is it just shown in the
> general area.  If it is the former, then this information can be taken into
> account.
>
> What i can do, and i presume that you all would agree, is to add this
> feature to the "not4osm" folder so then it could be used as an assistant for
> the person who is actually uploading the information.
>
> However,  I would also agree that adding this feature would be similar to
> me using the Aerial imagery and whereever i spot some "THING" that looks
> like a building, quickly tag it as building=yes.  ... this information is
> meaningless to the map user.  ... odds are, that right next to it is some
> other 'building'.   Unless the purpose is clearly stated, we dont need to
> include this feature.
>
> And YES, there are other point features which need to be looked at to see
> if they are actually useful.  As im going through the sharts, i'll now be
> looking at it.
>
> For example, when the feature lists 9 or so different feature types, the
> general practice for both GeoBase & CanVec is to state "-1" unknown  and "0"
> none ... i would suggest that these features be omitted from the import
> also.
>
> Any thoughts on that?
>
> Cheers,
> Sam
>
> P.S. I was thinking of adding another column to the 11 themes of CanVec
> charts, for "status"
> PPS. I am still finding some features that were accidentally missed when i
> was copying the data from the feature catelogue to the charts, so it's a
> good idea to cross-check with the .pdf catelogue to find out what the actual
> definition was. ~ probably 95% accurate, but always good to check :-)
>
> Hi all,
>>
>
>> Two weeks ago, I worked on the import of CanVec-Buildings using Map
>> feature
>>
> table on the wiki. I noticed at that time that point buildings imported as
>>
> building="yes" did not appear on the osm map. Sam probably rebembered the
>>
> discussion about it. So, I sent my question to the
>>
> tilesath...@openstreetmap.org. It appears that building="yes" will be
>>  
>
> rendered on the map only if they are polygons.
>>  
>
>
>> To conclude, I think there is no reason to import Canvec point building
>>
> unless they have specific functions. It may be true for other point
>>
> features. We should make sure before importing them.
>>
>
>> cheers,
>>
>
>> Michel
>>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec/Geobase point feature - Render

[Sam Vekemans]

Thanks,
Good call. :-)

The point feature "building=yes"  otherwise known as

point,CODE,2010010,canvec:CODE,2010010
point,CODE,2010010,building,yes

What it does is show up as a little house icon with JOSM

for the polygons, they show up as nice shapes.. and when clicked on would
simply state this this is a building.

outer,CODE,2010012,canvec:CODE,2010012
outer,CODE,2010012,building,yes
inner,CODE,2010012,canvec:CODE,2010012
inner,CODE,2010012,building,yes


I have not yet received the answer from NRCan about if the location of the
node is EXACTLY where the building actually is, or is it just shown in the
general area.  If it is the former, then this information can be taken into
account.

What i can do, and i presume that you all would agree, is to add this
feature to the "not4osm" folder so then it could be used as an assistant for
the person who is actually uploading the information.

However,  I would also agree that adding this feature would be similar to me
using the Aerial imagery and whereever i spot some "THING" that looks like a
building, quickly tag it as building=yes.  ... this information is
meaningless to the map user.  ... odds are, that right next to it is some
other 'building'.   Unless the purpose is clearly stated, we dont need to
include this feature.

And YES, there are other point features which need to be looked at to see if
they are actually useful.  As im going through the sharts, i'll now be
looking at it.

For example, when the feature lists 9 or so different feature types, the
general practice for both GeoBase & CanVec is to state "-1" unknown  and "0"
none ... i would suggest that these features be omitted from the import
also.

Any thoughts on that?

Cheers,
Sam

P.S. I was thinking of adding another column to the 11 themes of CanVec
charts, for "status"
PPS. I am still finding some features that were accidentally missed when i
was copying the data from the feature catelogue to the charts, so it's a
good idea to cross-check with the .pdf catelogue to find out what the actual
definition was. ~ probably 95% accurate, but always good to check :-)

Hi all,
>

> Two weeks ago, I worked on the import of CanVec-Buildings using Map feature
>
table on the wiki. I noticed at that time that point buildings imported as
>
building="yes" did not appear on the osm map. Sam probably rebembered the
>
discussion about it. So, I sent my question to the
>
tilesath...@openstreetmap.org. It appears that building="yes" will be
> 

rendered on the map only if they are polygons.
> 


> To conclude, I think there is no reason to import Canvec point building
>
unless they have specific functions. It may be true for other point
>
features. We should make sure before importing them.
>

> cheers,
>

> Michel
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] GeoBaseNHN

[Sam Vekemans]

Google Docs seems to be a little fuzzy right now, so here's the link to the
latest version.
http://sites.google.com/a/acrosscanadatrails.com/www/Home/geobaseNHN2osm0_02.zip

The Java files are included in the "lib" directory (i didn't create them)
but are available.  Ian Dees  was the one who put it all together. My script
just repeats the process to handle any shp files in 1 routeen.   It runs
through the rules.txt over and over again to match up the fields in
the dbf files to the appropriate OSM tag.

If you want to help edit the rules.txt files, in some cases it might be
easier to just tell me what the edits should be, then i can edit it on my
end (While Google Docs is still acting funny)  ... (same for the .bat files)

To view the .bat files just right-click & view in windows notepad :)

http://sites.google.com/a/acrosscanadatrails.com/www/Home/canvec2osm0_11.zip

Cheers,
Sam

On Mon, Mar 23, 2009 at 9:07 AM, Sam Vekemans
wrote:

> Yes, i will send you a link to the rules.txt files & the .bat files
> for the 2 programs.
> (just away from wifi right now)
>
> what i have yet to figure out is how to view the OSM files which are
> greater than 2 megs with JOSM.
> Anyone know?
>
>  I'll make a sample of the Sherbrooke NHN area -as that might help.
>
> Sam
>
>
> On 3/23/09, Jean-Sébastien Moreau 
> wrote:
> > Hi Sam,
> >
> > I would like to take a look at the source files of the program. Is it
> > available
> > somewhere?
> >
> > Thanks!
> >
> > Jean-Sebastien
> >
> > 
> > From: talk-ca-boun...@openstreetmap.org
> > [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Sam Vekemans
> > Sent: March 16, 2009 11:26 AM
> > To: Talk-CA OpenStreetMap; Michel Gilbert; Jason Reid; Steve Singer;
> Simon
> > Wood;
> > Daniel Begin
> > Subject: [Talk-ca] canvec2osm v0.09 now available
> >
> > Hi all,
> > The download files are available on my site
> > http://www.acrosscanadatrails.com/Home/canvec2osm0_09.zip
> >
> > I have created a sample of Sherbrooke QC, and Vancouver City & South
> > Vancouver
> > Delta area.
> > (as these are the most recient version)
> >
> >
> http://www.acrosscanadatrails.com/Home/osmsamplearea021e05SherbrookQC.zip
> >
> http://www.acrosscanadatrails.com/Home/geobasesamplearea021e05SherbrookQC.zip
> >
> http://www.acrosscanadatrails.com/Home/not4osmsamplearea021e05SherbrookQC.zip
> >
> >
> http://www.acrosscanadatrails.com/Home/osmsamplearea092g03lowerVancouver.zip
> >
> http://www.acrosscanadatrails.com/Home/geobasesamplearea092g03lowerVancouver.zip
> >
> http://www.acrosscanadatrails.com/Home/not4osmsamplearea092g03lowerVancouver.zip
> >
> > If you have a request for an area that you want to see, let me know.
> >
> > I changed the script a little to make a separate folder for the contours
> &
> > roads, as they are not needed for this set. as well as where the NTS
> border
> > is.
> >
> > For version 0.10 I will have the NHN all sorted out, but for now, you can
> > see
> > and compare existing OSM data with the canvec data available.
> >
> > I have carefully gone through the rules.txt file, and again it's
> available
> > as a
> > google doc for anyone to view.
> > http://docs.google.com/Doc?id=d2d8mrd_179gnhs54cw&hl=en
> >
> > I have made more edits and have gone through the 11 themes again, so now
> the
> > list of "to-be-proposed"  features is smaller.
> > I am making 'stub' pages, for all those tags that show up as 'red', in
> hopes
> > that others will be able to help out and create the proposal pages.
>  There
> > are
> > a few that i feel strongly that it should have it's own
> tag/rendering/icon,
> > but
> > others which are marginal. ... -Depending on what activities your
> interested
> > in, features would stand out more.
> >
> > #proposed feature (no presets)
> > line,CODE,1080021,natural,esker
> > outer,CODE,1350052,landuse,peat_cutting
> > point,CODE,1460040,natural,rocks
> > outer,CODE,1460092,sub_sea,reef
> > inner,CODE,1460092,sub_sea,reef
> > point,CODE,2010300,building,satellite_tracking_station
> > outer,CODE,2010302,building,satellite_tracking_station
> > point,CODE,2060010,amenity,chimney
> > point,CODE,2060030,man_made,chimney
> > point,CODE,2060040,man_made,chimney
> > point,CODE,2060040,type,flare_stack
> > point,CODE,2070010,amenity,theatre
> > point,CODE,2070010,drive_in,yes
> > outer,CODE,2070012,amenity,theatre
> > outer,CODE,2070012,drive_in,yes
> > point,CODE,2080010,man_made,storage
> > point,CODE,2080010,type,liquid_storage_tank
> > outer,CODE,2360012,landuse,industrial
> > outer,CODE,2360012,type,auto_wrecker
> > point,CODE,2380010,landuse,reservoir  (needs ICON)
> > point,CODE,2440010,man_made,tower
> > point,CODE,2440010,contents,silage
> > point,CODE,2440010,height,>20
> > point,CODE,2530040,man_made,fire_tower
> > point,CODE,2530030,tower,clearance
> > point,CODE,2530010,man_made,beacon
> > point,CODE,2530010,type,radio_tower
> >
> >
> > Cheers,
> > Sam Vekemans
> > Across Canada Trails
> >
> >
> >
> >
>

Re: [Talk-ca] canvec2osm source code

[Sam Vekemans]

Yes, i will send you a link to the rules.txt files & the .bat files
for the 2 programs.
(just away from wifi right now)

what i have yet to figure out is how to view the OSM files which are
greater than 2 megs with JOSM.
Anyone know?

 I'll make a sample of the Sherbrooke NHN area -as that might help.

Sam


On 3/23/09, Jean-Sébastien Moreau  wrote:
> Hi Sam,
>
> I would like to take a look at the source files of the program. Is it
> available
> somewhere?
>
> Thanks!
>
> Jean-Sebastien
>
> 
> From: talk-ca-boun...@openstreetmap.org
> [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Sam Vekemans
> Sent: March 16, 2009 11:26 AM
> To: Talk-CA OpenStreetMap; Michel Gilbert; Jason Reid; Steve Singer; Simon
> Wood;
> Daniel Begin
> Subject: [Talk-ca] canvec2osm v0.09 now available
>
> Hi all,
> The download files are available on my site
> http://www.acrosscanadatrails.com/Home/canvec2osm0_09.zip
>
> I have created a sample of Sherbrooke QC, and Vancouver City & South
> Vancouver
> Delta area.
> (as these are the most recient version)
>
> http://www.acrosscanadatrails.com/Home/osmsamplearea021e05SherbrookQC.zip
> http://www.acrosscanadatrails.com/Home/geobasesamplearea021e05SherbrookQC.zip
> http://www.acrosscanadatrails.com/Home/not4osmsamplearea021e05SherbrookQC.zip
>
> http://www.acrosscanadatrails.com/Home/osmsamplearea092g03lowerVancouver.zip
> http://www.acrosscanadatrails.com/Home/geobasesamplearea092g03lowerVancouver.zip
> http://www.acrosscanadatrails.com/Home/not4osmsamplearea092g03lowerVancouver.zip
>
> If you have a request for an area that you want to see, let me know.
>
> I changed the script a little to make a separate folder for the contours &
> roads, as they are not needed for this set. as well as where the NTS border
> is.
>
> For version 0.10 I will have the NHN all sorted out, but for now, you can
> see
> and compare existing OSM data with the canvec data available.
>
> I have carefully gone through the rules.txt file, and again it's available
> as a
> google doc for anyone to view.
> http://docs.google.com/Doc?id=d2d8mrd_179gnhs54cw&hl=en
>
> I have made more edits and have gone through the 11 themes again, so now the
> list of "to-be-proposed"  features is smaller.
> I am making 'stub' pages, for all those tags that show up as 'red', in hopes
> that others will be able to help out and create the proposal pages.  There
> are
> a few that i feel strongly that it should have it's own tag/rendering/icon,
> but
> others which are marginal. ... -Depending on what activities your interested
> in, features would stand out more.
>
> #proposed feature (no presets)
> line,CODE,1080021,natural,esker
> outer,CODE,1350052,landuse,peat_cutting
> point,CODE,1460040,natural,rocks
> outer,CODE,1460092,sub_sea,reef
> inner,CODE,1460092,sub_sea,reef
> point,CODE,2010300,building,satellite_tracking_station
> outer,CODE,2010302,building,satellite_tracking_station
> point,CODE,2060010,amenity,chimney
> point,CODE,2060030,man_made,chimney
> point,CODE,2060040,man_made,chimney
> point,CODE,2060040,type,flare_stack
> point,CODE,2070010,amenity,theatre
> point,CODE,2070010,drive_in,yes
> outer,CODE,2070012,amenity,theatre
> outer,CODE,2070012,drive_in,yes
> point,CODE,2080010,man_made,storage
> point,CODE,2080010,type,liquid_storage_tank
> outer,CODE,2360012,landuse,industrial
> outer,CODE,2360012,type,auto_wrecker
> point,CODE,2380010,landuse,reservoir  (needs ICON)
> point,CODE,2440010,man_made,tower
> point,CODE,2440010,contents,silage
> point,CODE,2440010,height,>20
> point,CODE,2530040,man_made,fire_tower
> point,CODE,2530030,tower,clearance
> point,CODE,2530010,man_made,beacon
> point,CODE,2530010,type,radio_tower
>
>
> Cheers,
> Sam Vekemans
> Across Canada Trails
>
>
>
>

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Address ranges

[Jean-Sébastien Moreau]

I agree with Richard.

I don't think we should worry to much about the size of the DB. Being compatible
with the current approach in OSM is far more important from my point of view.

However, it would be important to agree on some rules on the clipping-tagging
operations.
For example, Richard suggest a 3 meters shift on each side. I think its
raisonnable but in which projection? These meter values should first be
converted in decimal degrees.

It's nice to see some discussions about adding this information to OSM.

Keep up the good work!

Jean-Sebastien

Quoting Richard Weait :

> On Sun, 2009-03-22 at 12:02 -0400, Steve Singer wrote:
> >
> > On Sat, 21 Mar 2009, Richard Weait wrote:
> [ ... ]
> > > This does triple the db size (node and way count) for each road with
> > > address info.  But it's just Canadian road data, it's not like we're
> > > tripling the size of the US data
> >
> > Tripling the number of nodes+ways in the DB isn't something we want to do
> > lightly.
>
> Agreed.  Not lightly.  I see the address data as worthwhile and consider
> Karlsruhe a wonderful example of some of the very best of OSM.  How much
> data are we talking about in the grand scheme of things?  Canadian road
> data +200%, Canadian data overall +100, all of it compared to planet,
> perhaps +5%.  So I see it as a relatively big deal for us, not so much
> on the scale of all of OSM.
>
> Just in case, I've asked the OSM Foundation if Canada would be making
> too much of a dent in project growth based in this addressing data.  I
> expect that we'll be fine.  It's great data and belongs in OSM.
>
> [ ... ]
> > >
> > > Wonderful news that you are looking at this.
> >
> > I haven't yet decided what I'll work on next, it might be this, or it might
> be
> > trying to match up roadnames from statscan.
>
> That, my friend, sounds like win:win for Canadian data!
>
> Best regards,
> Richard
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ca
>
>




___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca