Re: [Talk-ca] Light rail mapping questions

[Michael Reichert]

Hi Mike,

Am 18.10.2016 um 03:52 schrieb Mike Boos:
> Along on-road sections, the dedicated rail right-of-way moves from
> centre-running to the outsides of the street at certain intersections. (A
> by-product of some of the political compromises in route choices.) Does
> anyone know of any examples of tracks going from the centre to the side of
> the road with traffic lanes in OSM? I expect these are going to look messy.

Look at any German, Austrian or Swiss city of your choice where every
tram track is mapped as a single way in OSM (i.e. no tracks=2). I need
more details (show us photos) to give a useful answer.

> There are also portions of the line that will share track with a freight
> corridor. From what I can tell, convention appears to be to tag it with the
> heavier mode, i.e. railway=rail instead of railway=light_rail. However, the
> use of the track for freight is quite small - at most one freight train
> to/from Elmira uses the track at night, when light rail service won't be
> operating. Should the track still be marked as 'rail' instead of
> 'light_rail,' or should we attempt to have the tags represent the dominant
> use? (At present, some of these are tagged as railway=construction, even
> though the freight train has been consistently using it overnight. This
> section is also largely complete.)

Yes. If the track is still usable for freight trains (even if limited to
certain hours), it is a normal railway track and therefore gets
railway=rail. What you describe is called "Karlsuhe model" – don't
confuse it with our tagging scheme at OSM. ;-)

I assume, that some people of Grand River Transit have visited the
German cities Karlsruhe and/or Kassel. :-) The first one has been
operating a tram-train system for more than 40 years.

https://en.wikipedia.org/wiki/Karlsruhe_Stadtbahn
https://en.wikipedia.org/wiki/Kassel_RegioTram

Tag the tracks as they look like. Sections where tracks share space with
cars [1] are railway=tram. Where the trams are physically separated from
the traffic [2], it's a railway=light_rail. That's how tagging works in
cities which only have *one* tram/light rail system. If the city has two
or three (low-floor tram and high-floor light rail; some German cities),
it becomes more difficult because we also try to get the systems
distinguishable (there are use cases). But that is not important now and
the reason why Germans discuss correct tagging of trams, light rails and
subways at their OSM Forum over multiple pages and threads. :-)

> Further, there is gauntlet track to allow freight trains to pass station
> platforms. Do we tag the track closest to the platform as
> railway=light_rail and the outer track as railway=rail? There's some
> discussion here on gauntlet tracks here that suggests this is the case in
> Europe: http://forum.openstreetmap.org/viewtopic.php?id=29131

It is the case in Kaufungen near the city of Kassel which has a
Karlsruhe-like tram-train system ("Regiotram").

https://commons.wikimedia.org/wiki/File:Haltestelle_Niederkaufungen_Mitte_02.JPG

Yes, the track for heavy trains is a normal train track (railway=rail)
while the outer ones can only be used by light rail vehicles due to the
smaller structure gauge. Therefore the light rail track gets
railway=light_rail. Because we map one way per track at the centerline
of the track, there are two (in Kaufungen three) parallel tracks and all
get railway:interlaced=yes. This is useful for routing engines.

If there were up to date Mapillary photos, I could give more and better
advice. (Mapillary photos by pedestrians are better because are located
on the sidewalk)

Greetings from Karlsruhe

Michael


[1]
https://www.mapillary.com/app/?focus=photo=EztyFQ4j2CHqglj_C-Uilg=48.99870833326=8.3937401=17
[2]
https://www.mapillary.com/app/?focus=photo=gejtgJYKdJrqZ_8M0zcDFQ=50.935379=6.957689=17


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)




signature.asc
Description: OpenPGP digital signature
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] City of Ottawa imported buildings & addresses

[john whelan]

I think it has been mentioned that unfortunately a number of buildings in
Ottawa that were deleted already have some of the attributes that Stats
Canada are after.

I think step one is hands off any mapping of buildings for the moment in
Ottawa.  That unfortunately includes Stats crowd sourcing initiative until
the reverts are done.


*​Note to Bjenk ​can you put a sorry out of service notice up or something?*

​Note to Frederick can you let us know when they can continue?​

Step two will be restart the Stats Canada web site and data collection.

Step three will be for someone to communicate with the import forum
​etc ​
as per the wiki.  I think all our ducks and processes are lined up its just
a matter of explaining them.

Finally then I think restart the import process but very slowly and with
more care.

Stats Canada can work without the building import but there is
​adanger that new inexperienced mappers drawing building outlines in iD
will produce the sort of results both Pierre and I have seen in HOT and I
think that is to be avoided if at all possible.

Thanks for the update Frederick.

Cheerio John

On 18 Oct 2016 1:54 pm, "Frederik Ramm"  wrote:

> Hi,
>
> On 10/17/2016 11:59 PM, Frederik Ramm wrote:
> > The person responsible for cleaning up a poor revert should be the
> > person who ran it ;) it's only 30% complete and will run far into the
> > night in my time zone and I'll have to check on it after getting up. I'm
> > confident all will be fixed when you get up tomorrow morning.
>
> Unfortunately the import was larger than expected and the revert drags
> on. Meanwhile, a couple of accounts have been newly created by parties
> unknown ("addxy_imports", "ottawa_import") and these have (accidentally
> or purposefully) interfered with the revert, meaning that it will take
> even longer for me do this right.
>
> I would like to appeal to all involved parties to show some maturity.
> The import was in clear violation of established processes; it must be
> reverted, and then the community can - calmly and without any time
> pressure - decide what they want to do with the data.
>
> I haven't analysed the import in depth but I have seen a couple of
> examples where a perfectly well mapped building was wiped clean and
> replaced with one that was not at all better - this is clearly something
> we don't want to see in an import, it is a technical (or procedural)
> shortcoming that would definitely have been pointed out had there been a
> proper discussion beforehand.
>
> The requirement to talk about imports before you act is not an
> unnecessary bueraucratic hurdle; it is intended to avoid disappointment
> on all sides. An import that fears the broad daylight is probably one
> that should not be attempted at all!
>
> I should maybe have made that clearer in my initial email but I'm acting
> here as a member of the OSMF's data working group in response to a
> legitimate complaint, not as a German mapper seeking trouble. I
> sincerely ask everyone involved to keep calm and let the revert complete
> cleanly.
>
> I see that user LogicalViolinist has already found fields of endeavour
> outside of Canada for the time being.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] The Statistics Canada Project

[Pierre Béland]

Bonjour John 
Je suis d'accord avec toi. Sur le terrain, oui il y a des éditeurs tels que 
OSMAnd fonctionnant a la fois sur Android et iOS qui permettent de simplifier 
le travail et s'assurer de placer les POI sur les bons immeubles.  Il s'agit 
effectivement d'ajouter un POI au milieu de l'immeuble avec les descriptifs 
appropriés.

Je ne recommande pas ID pour modifier la géométrie des immeubles. Toi et moi 
pouvons longuement parler de tous les problèmes dans le contexte des réponses 
humanitaires où les nouveaux contributeurs tracent des immeubles très 
fantaisistes. Cela ajoute une surcharge de travail aux contributeurs 
expérimentés qui doivent ensuite corriger.  
Pierre 


  De : john whelan 
 À : Talk-CA OpenStreetMap  
 Envoyé le : mardi 18 octobre 2016 7h52
 Objet : Re: [Talk-ca] The Statistics Canada Project
   
When I looked through the existing buildings I came across a tag that was ele 
often with a value of 2 or 3.  I suspect this is the number of stories and the 
same as building:levels which is in wiki/Map_Features.  Could any one confirm 
this as it is one of the attributes that Stats Canada is looking for.

If it is would there be any great objection to me changing the tag to 
building:levels as recommended by the wiki/Map_Features?  The alternative would 
be to have both tags on the building.

The other thought was although Stats Canada is promoting a customised version 
of iD reality is it a lot easier to carry a smartphone or small tablet and 
enter tags in the field.  There are a number of editors that run under Android 
etc but unfortunately although its easy to add tags to a node adding them to a 
building outline is more difficult. 

Currently for buildings such as strip malls we have the idea of a building 
outline with nodes for each store.  Often the address is on the building 
outline but other details such as coffee shop etc are on the nodes.  I'm 
wondering if having a node within the building that could be edited by such 
things as OSMand etc might be a reasonable compromise.  It would avoid 
transcription errors, first writing down the information then returning home 
and entering it in iD.

We can build a list of buildings that are missing some tags that Stats Canada 
are interested in but how does one draw them to attention to the mappers with 
their missing tags?  A customised version of walking papers perhaps?

Any thoughts on any of the above would be welcome.

Thanks John

On 18 October 2016 at 06:12, James  wrote:

Also I forgot about this one: https://lists.openstreetmap. 
org/pipermail/talk-ca/2015- August/006602.html which was on the import list and 
talk-ca(I forgot because it was so long ago) Which everyone seems to be on 
board, except for the license. Solicense is compatible now...
On Oct 17, 2016 9:11 PM, "James"  wrote:

I'm the one running the tasking manager.
On Oct 17, 2016 9:08 PM, "AJ Ashton"  wrote:

Hi John,

Thanks for the writeup. I think this is the first post that's made it fully 
clear what is going on. As I was re-reading the previous StatCan thread earlier 
today I seemed to be missing something - now I guess it was context available 
to those who attended in-person meetings. I don't think it was even clear to 
the list until now how much in-person community discussion has been happening.

Basically the issue is that all the online discussion about this looks to have 
been about the StatCan crowdsourcing half of the project and none at all about 
the building import half. I didn't pay too much attention to the original 
StatCan thread at the time because it so clearly sounded like a local mapping 
project with no large-scale import component.

Unfortunately I no longer live in Ottawa and couldn't have made it to the 
meetings. However I lived there for many years, have done a lot of mapping 
there, and have a continued interest in the area. I would still like to see the 
the building import happen and even help out where I can. But I think it's 
important to do more planning and discussion on this list and the imports list, 
and to take things in smaller and more manageable chunks.

I guess the next step would be to continue on a proper path to import the 
buildings per the guidelines per http://wiki.openstreetmap.org/ 
wiki/Import/Guidelines . This would include:

- Wiki documentation of the where the data is, what it contains & its license / 
permissions
- A plan to conflate with existing data - preserving history, keeping existing 
attributes, and merging addresses onto buildings where possible before the data 
is uploaded
- A specific plan for uploading the data. Eg how the data will be divided up 
into chunks and step-by-step instructions for JOSM, etc. A task server was 
mentioned several times - who is running this and how can others participate?
- A proper review on the imports mailing list

I don't necessarily agree 

Re: [Talk-ca] The Statistics Canada Project

[Denis Carriere]

Hey AJ,

Thanks for understanding, this project has been discussed many times at the
local OSM Ottawa Meetup and we've proven this method of import is very
efficient on smaller scale projects.

We might of leaned a bit too much on StatsCan to tackle the "legal" part of
it, however everything has been sorted out between the City of Ottawa, OSM
& Open Data license. It might just not be as documented on the internet
since StatsCan doesn't promote the use of internet in their office and work
mostly in an offline environment.

There are two datasets we are currently working with, building footprints &
address points. The address one is currently released under the OpenData
Ottawa portal and the building footprint has been released, however not
available yet under the OpenData portal, they are trying to figure out
which portal to disseminate to.

Currently the TM project is private, log in and we can grant you access.

http://tasks.osmcanada.ca/project/34


*Workflow*


*Step 1:* Select a Tile & Start Mapping

*Step 2:* Edit with JOSM

*Step 3:* Apply an inverse filter to find any existing databuilding=*

*Step 4:* Download data - Found in the *Extra Instructions*

*Step 5:* Add feature or merge new data with existing features *(try not to
delete features)*. Check for any existing buildings that might create
conflicts (keep existing, merge tags or only update building footprint)

*Step 6:* Merge address points to building using JOSM address plugin.

*Step 7:* Click JOSM validate and fix any errors or warnings that appear
before submitting your changset.
*Completion Status*

Since adding all the buildings can take a lot of time uploading a single
changeset and the validation requires having the building footprint +
address be available. We've divided the task into two parts "Done" &
"Validation".
*Done*

Once all the building footprints & address are added, you can mark the tile
as *Done *and the next step would be to validate the tile.
*Validation*

This step will require a lot of time and effort. Here are some of the basic
validation process:

   1. Align Address nodes to the center of the building footprints.
   2. Merge Address nodes with building footprints using the JOSM address
   plugin.
   3. Any buildings that don't have an address (Sheds, garages, etc...)
   either tag them with a specific tag or remove them since it causes
   confusion to clearly identify the primary building.
   4. Replace all building footprints from building=yes with an appropriate osm
   building tag , we've
   been tagging all the residential houses withbuilding=residential.
   5. Use the validate JOSM process to detect any warnings or errors and
   fix them accordingly. You only need to validate the address & building
   footprints, however you decide to fix other OSM related issues, fill your
   boots!




*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

*Twitter: @DenisCarriere *
*OSM: DenisCarriere *
GitHub: DenisCarriere 
Email: carriere.de...@gmail.com

On Mon, Oct 17, 2016 at 9:07 PM, AJ Ashton  wrote:

> Hi John,
>
> Thanks for the writeup. I think this is the first post that's made it
> fully clear what is going on. As I was re-reading the previous StatCan
> thread earlier today I seemed to be missing something - now I guess it was
> context available to those who attended in-person meetings. I don't think
> it was even clear to the list until now how much in-person community
> discussion has been happening.
>
> Basically the issue is that all the online discussion about this looks to
> have been about the StatCan crowdsourcing half of the project and none at
> all about the building import half. I didn't pay too much attention to the
> original StatCan thread at the time because it so clearly sounded like a
> local mapping project with no large-scale import component.
>
> Unfortunately I no longer live in Ottawa and couldn't have made it to the
> meetings. However I lived there for many years, have done a lot of mapping
> there, and have a continued interest in the area. I would still like to see
> the the building import happen and even help out where I can. But I think
> it's important to do more planning and discussion on this list and the
> imports list, and to take things in smaller and more manageable chunks.
>
> I guess the next step would be to continue on a proper path to import the
> buildings per the guidelines per http://wiki.openstreetmap.org/
> wiki/Import/Guidelines . This would include:
>
> - Wiki documentation of the where the data is, what it contains & its
> license / permissions
> - A plan to conflate with existing data - preserving history, keeping
> existing attributes, and merging addresses onto buildings where possible
> before the data is uploaded
> - A specific plan for uploading the data. Eg how 

Re: [Talk-ca] Telenav mapping turn restrictions

[Begin Daniel]

Go with the recommended scheme as described on the wiki.
Daniel

From: Martijn van Exel [mailto:m...@rtijn.org]
Sent: Monday, 17 October, 2016 23:53
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] Telenav mapping turn restrictions

Hi all,

I wanted to give you a heads up that my colleagues on the Telenav map team are 
starting work on adding turn restrictions in Toronto, Montréal, and later on 
also Vancouver, Ottawa and Calgary. We are using OpenStreetView and Mapillary 
as sources. If you have any questions or concerns, please reach out to me and 
we will address it right away.

For conditional (time-restricted) turn restrictions, we intend to use the 
schema described in 
http://wiki.openstreetmap.org/wiki/Conditional_restrictions. We encounter a 
more complex mapping of conditional turn restrictions sometimes, where mappers 
have used day_on / day_off and hour_on / hour_off. This is uncommon and as far 
as I know not recommended for mapping time-restricted turn restrictions. If we 
encounter these, our proposal would be to remove these tags and if necessary 
replace them with the preferred scheme as described on the wiki. Opinions?

Best,
Martijn

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

Re: [Talk-ca] The Statistics Canada Project

[john whelan]

When I looked through the existing buildings I came across a tag that was
ele often with a value of 2 or 3.  I suspect this is the number of stories
and the same as building:levels which is in wiki/Map_Features.  Could any
one confirm this as it is one of the attributes that Stats Canada is
looking for.

If it is would there be any great objection to me changing the tag to
building:levels as recommended by the wiki/Map_Features?  The alternative
would be to have both tags on the building.

The other thought was although Stats Canada is promoting a customised
version of iD reality is it a lot easier to carry a smartphone or small
tablet and enter tags in the field.  There are a number of editors that run
under Android etc but unfortunately although its easy to add tags to a node
adding them to a building outline is more difficult.

Currently for buildings such as strip malls we have the idea of a building
outline with nodes for each store.  Often the address is on the building
outline but other details such as coffee shop etc are on the nodes.  I'm
wondering if having a node within the building that could be edited by such
things as OSMand etc might be a reasonable compromise.  It would avoid
transcription errors, first writing down the information then returning
home and entering it in iD.

We can build a list of buildings that are missing some tags that Stats
Canada are interested in but how does one draw them to attention to the
mappers with their missing tags?  A customised version of walking papers
perhaps?

Any thoughts on any of the above would be welcome.

Thanks John

On 18 October 2016 at 06:12, James  wrote:

> Also I forgot about this one: https://lists.openstreetmap.
> org/pipermail/talk-ca/2015-August/006602.html which was on the import
> list and talk-ca(I forgot because it was so long ago)
>
> Which everyone seems to be on board, except for the license. Solicense
> is compatible now...
>
> On Oct 17, 2016 9:11 PM, "James"  wrote:
>
>> I'm the one running the tasking manager.
>>
>> On Oct 17, 2016 9:08 PM, "AJ Ashton"  wrote:
>>
>>> Hi John,
>>>
>>> Thanks for the writeup. I think this is the first post that's made it
>>> fully clear what is going on. As I was re-reading the previous StatCan
>>> thread earlier today I seemed to be missing something - now I guess it was
>>> context available to those who attended in-person meetings. I don't think
>>> it was even clear to the list until now how much in-person community
>>> discussion has been happening.
>>>
>>> Basically the issue is that all the online discussion about this looks
>>> to have been about the StatCan crowdsourcing half of the project and none
>>> at all about the building import half. I didn't pay too much attention to
>>> the original StatCan thread at the time because it so clearly sounded like
>>> a local mapping project with no large-scale import component.
>>>
>>> Unfortunately I no longer live in Ottawa and couldn't have made it to
>>> the meetings. However I lived there for many years, have done a lot of
>>> mapping there, and have a continued interest in the area. I would still
>>> like to see the the building import happen and even help out where I can.
>>> But I think it's important to do more planning and discussion on this list
>>> and the imports list, and to take things in smaller and more manageable
>>> chunks.
>>>
>>> I guess the next step would be to continue on a proper path to import
>>> the buildings per the guidelines per http://wiki.openstreetmap.org/
>>> wiki/Import/Guidelines . This would include:
>>>
>>> - Wiki documentation of the where the data is, what it contains & its
>>> license / permissions
>>> - A plan to conflate with existing data - preserving history, keeping
>>> existing attributes, and merging addresses onto buildings where possible
>>> before the data is uploaded
>>> - A specific plan for uploading the data. Eg how the data will be
>>> divided up into chunks and step-by-step instructions for JOSM, etc. A task
>>> server was mentioned several times - who is running this and how can others
>>> participate?
>>> - A proper review on the imports mailing list
>>>
>>> I don't necessarily agree with every single rule in the import
>>> guidelines, but they are what the community has decided on and I think for
>>> the most part they help avoid the kinds of issues I had with deleted and
>>> duplicated data in Ottawa.
>>>
>>> --
>>>   AJ Ashton
>>>   a...@ajashton.ca
>>>
>>>
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] The Statistics Canada Project

[James]

Also I forgot about this one:
https://lists.openstreetmap.org/pipermail/talk-ca/2015-August/006602.html
which was on the import list and talk-ca(I forgot because it was so long
ago)

Which everyone seems to be on board, except for the license. Solicense
is compatible now...

On Oct 17, 2016 9:11 PM, "James"  wrote:

> I'm the one running the tasking manager.
>
> On Oct 17, 2016 9:08 PM, "AJ Ashton"  wrote:
>
>> Hi John,
>>
>> Thanks for the writeup. I think this is the first post that's made it
>> fully clear what is going on. As I was re-reading the previous StatCan
>> thread earlier today I seemed to be missing something - now I guess it was
>> context available to those who attended in-person meetings. I don't think
>> it was even clear to the list until now how much in-person community
>> discussion has been happening.
>>
>> Basically the issue is that all the online discussion about this looks to
>> have been about the StatCan crowdsourcing half of the project and none at
>> all about the building import half. I didn't pay too much attention to the
>> original StatCan thread at the time because it so clearly sounded like a
>> local mapping project with no large-scale import component.
>>
>> Unfortunately I no longer live in Ottawa and couldn't have made it to the
>> meetings. However I lived there for many years, have done a lot of mapping
>> there, and have a continued interest in the area. I would still like to see
>> the the building import happen and even help out where I can. But I think
>> it's important to do more planning and discussion on this list and the
>> imports list, and to take things in smaller and more manageable chunks.
>>
>> I guess the next step would be to continue on a proper path to import the
>> buildings per the guidelines per http://wiki.openstreetmap.org/
>> wiki/Import/Guidelines . This would include:
>>
>> - Wiki documentation of the where the data is, what it contains & its
>> license / permissions
>> - A plan to conflate with existing data - preserving history, keeping
>> existing attributes, and merging addresses onto buildings where possible
>> before the data is uploaded
>> - A specific plan for uploading the data. Eg how the data will be divided
>> up into chunks and step-by-step instructions for JOSM, etc. A task server
>> was mentioned several times - who is running this and how can others
>> participate?
>> - A proper review on the imports mailing list
>>
>> I don't necessarily agree with every single rule in the import
>> guidelines, but they are what the community has decided on and I think for
>> the most part they help avoid the kinds of issues I had with deleted and
>> duplicated data in Ottawa.
>>
>> --
>>   AJ Ashton
>>   a...@ajashton.ca
>>
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca