Would stop_area_group be a solution here? That was proposed a while back
but I'm not sure if it was officially accepted.
On Sat, Jan 22, 2022, 07:36 Alexey Z via Talk-transit <
talk-transit@openstreetmap.org> wrote:
>
> Hello.
>
> Let me raise a question/appeal about stop_area relation. PTv2 is
On Tue, 1 Jun 2021 at 13:34, Philip Barnes wrote:
> On Tue, 2021-06-01 at 13:07 -0400, Jarek Piórkowski wrote:
> > On Tue, Jun 1, 2021, 12:38 Dave F via Talk-transit <
> > talk-transit@openstreetmap.org> wrote:
> > > On 01/06/2021 16:11, Christopher Parker wrote
On Tue, Jun 1, 2021, 14:15 Dave F via Talk-transit <
talk-transit@openstreetmap.org> wrote:
>
>
> On 01/06/2021 18:07, Jarek Piórkowski wrote:
>
> On Tue, Jun 1, 2021, 12:38 Dave F via Talk-transit <
> talk-transit@openstreetmap.org> wrote:
>
>> On 01/
Without route relations, OSM shows where you can get on the train/vehicle,
but not where you can go
On Tue, Jun 1, 2021, 10:58 Dave F via Talk-transit <
talk-transit@openstreetmap.org> wrote:
> What's wrong with consulting a timetable?
>
> Maps show you where you can go, timetables tell you when
On Thu, 28 Jan 2021 at 05:57, Janko Mihelić wrote:
> I'm wondering how other mappers are solving this problem. The gtfs of my
> public transport provider (Zagreb) has stops that have one gtfs:stop_id when
> it is used as a middle stop in a rute, and a different gtfs:stop_id when it
> is the
Personally I wouldn't recommend this tagging (especially on the linked
stop where service is no better than every 20 minutes), but the Berlin
and German tagging community is large enough that IMO this is
something they may well decide to do internally - so could also ask on
a German list?
--Jarek
For anyone interested, it appears the link for this week's news should
be https://weeklyosm.eu/archives/13839
On Sun, 18 Oct 2020 at 06:13, weeklyteam wrote:
>
> The weekly round-up of OSM news, issue # 534,
> is now available online in English, giving as always a summary of a lot of
> things
On Thu, 15 Oct 2020 at 18:58, Alex Dhawan wrote:
> Would defiantly have to be a ballpark figure for any some of capacity metric.
> Could maybe also do capacity:peak/offpeak or
> capacity:morning/afternoon/evening/night?
Not quite as elegant, but in OSM tagging scheme this could be
On Sat, 18 Jul 2020 at 13:17, Daniel Capilla wrote:
> When we started mapping the bus routes in Málaga, Alan Grant and I came
> to the conclusion that it was not necessary to add "stop_area" relations
> due to the type of bus stops in Málaga, [2] where there are no actual
> stop areas (only a
On Thu, 16 Jul 2020 at 11:30, Andrew Deng via Talk-ca
wrote:
> Hello, I believe Yonge Street in Toronto and York Region (Regional Road 1)
> should be tagged as highway=primary rather than highway=secondary as it is
> tagged now.
> Here are some reasons I believe why:
> 1) Yonge Street is
The limitation is generally licensing.
Openstreetmap can accept an import of data that is freely licensed, but the
criteria for "freely" are fairly strict - most Canadian cities' "open data"
don't meet it. If you're familiar with Creative Commons, the license will
likely have to be as free or
Just to add an opinion: I think this tag is a great idea.
I don't care as much for promoting OpenStreetMap in this case - I'm
not sure we have a critical density of surveyors to make this a
valuable resource in Canada or individual cities. And I'm not sure
this would be a great project to
Thanks for the summary, weeklyteam!
The tagging proposal
https://wiki.openstreetmap.org/wiki/Proposed_features/park_drive might
be of interest to Canadian mappers. It is intended to cover carpool
lots. At least in Ontario, many MTO carpool lots are tagged with
park_ride= (park & ride) and
Hi Joan, this is the Canadian mailing list, not the Catalan one :)
Thanks,
--Jarek
On Sun, 3 Nov 2019 at 19:59, Joan Quintana wrote:
>
> Aquesta importació ha de ser fàcil, només són 25 parkings amb carsharing.
> El dubte és l'etiqueta.
> A [1] es proposa dues etiquetes:
>
> amenity=parking
>
Thanks for the summaries, Weekly Team!
Of particular interest should be the upcoming release of a game that
takes in data from OSM, which might sometimes result in edits adding
fake data for sake of having data in the game, as we saw with Pokémon
Go:
"The Scandinavian gaming website IGN Nordic
On Sun, 6 Oct 2019 at 12:23, weeklyteam wrote:
> The weekly round-up of OSM news, issue # 480,
> is now available online in English, giving as always a summary of all things
> happening in the openstreetmap world:
> http://www.weeklyosm.eu/en/archives/12433/
>
> Enjoy!
>
> Did you know that you
Yeah, Canada Post currently considers postal codes their commercial
data. Crowd-sourcing all or a substantial amount of full codes seems
infeasible. Crowd-sourcing the forward sortation areas (the first A1A)
seems difficult since verifiability is going to be a problem
especially around the edges
Hi all,
To be a bit more positive:
If we want to get buildings on the map, but we can't get Canada-wide
data improved by Statcan to a standard acceptable to all mappers in
Canada, IMO the best bet will be to split this into much smaller
batches and support local mappers who would be interested
On Fri, 27 Sep 2019 at 11:45, john whelan wrote:
> ...
> About that time an American mapper, Nate, who was living in Toronto ...
Sorry, one more thing.
Nate was an active editor in Toronto at the time of the initial import
conflict/objection and has remained so as regularly as we can ask of
any
On Fri, 27 Sep 2019 at 20:43, John Whelan wrote:
> The Stat Can data comes directly from the municipalities so each municipality
> will have a different quality of data. The Microsoft and NR Can data maybe
> more consistent.
Statcan could improve the data and make it more consistent. On this
On Fri, 27 Sep 2019 at 11:45, john whelan wrote:
> I do know that a number of departments and agencies would like to use
> buildings and although they can use the open data sources using OSM would be
> more convenient.
Then you can encourage these agencies to urge Statcan to improve the
9, 2019, 9:57 PM Pierre Béland via Talk-ca,
> wrote:
>>
>> Cela semble bien préciser, mais les collègues d'Ontario pourront mieux
>> répondre.
>>
>> Pierre
>>
>> Envoyé à partir de Yahoo Courriel sur Android
>>
>> Le lun., sept. 9 20
ther bilingual areas, or am
I missing a pitfall?
Thanks,
--Jarek
On Mon, 9 Sep 2019 at 08:51, Pierre Béland wrote:
>
> Marek
>
> Ces instructions ne s'appliquent pas à toutes les provinces. Il faudrait donc
> indiquer sur la page wiki à quelles provinces elles s'appliquent
>
>
nist
[5] recipients on August 27: Undearius, zzptichka, DannyMcD, egli,
OttawaHiking, MaximusSayan
On Wed, 3 Apr 2019 at 21:11, Jarek Piórkowski wrote:
>
> Hi all,
>
> I'm responding to the saints discussion I started last month. (Finally -
> sorry.)
>
> Question: does anyone identi
On Tue, 6 Aug 2019 at 06:23, Dave F via Talk-transit
wrote:
> On 06/08/2019 07:08, Janko Mihelić wrote:
> > An app would route from one station to the other, and show status as if you
> > were driving. There could be a tag that would say if the route goes through
> > motorways, tolled roads,
Fundamentally this isn't that different from long-distance train services.
In practice, at least in Germany, Flixbus is one of very few bus
operators that have 1) daily/weekly schedules and 2) tickets they sell
to anyone (rather than a charter service). However I am aware
elsewhere this might not
-9701
>
> On Jul 8, 2019, at 09:25, Jarek Piórkowski wrote:
>
> I don't know if that is the case here, but I've also seen objects
> straight-up missing from the cycle map layer. I think its import of new and
> changed ways is sometimes buggy.
> https://www.openstreetmap.
I would expect this to be the same as the many "1st Street", "Twenty
Second Street", "16A Street", or "96 Avenue" we have in English
Canada: we go by what is signed and the software adapts. Hardcoding a
special case mapping "1e Avenue" within Québec to pronunciation
"Première Avenue" would be
Hi Pierre,
Thanks for sending these out.
Can you briefly confirm what the "building.geojson",
"building_extring.geojson", "building_extring_orthogonal.geojson"
files represent? I'm not really familiar with the terms, perhaps
because I don't have much of a GIS or geometry background. Is the
On Tue, 28 May 2019 at 07:24, Mateusz Konieczny wrote:
> In this bot edit:
>
> * Editing is limited to Poland
> * Editing is limited to nodes with public_transport=platform bus=yes
> * Nodes with nearby (within 250 meters) highway=bus_stop are ignored[1]
> * Elements with highway tag are skipped
On Mon, 13 May 2019 at 11:49, Dave F via Talk-transit
wrote:
> If Philip really wants a router to tell him where the nearest
> shelter (surely you can just look around you),
You're joking?!
The entire OpenStreetMap could be waved away with the phrase "surely
you can just look around you". Why
On Mon, 13 May 2019 at 12:13, Clifford Snow wrote:
> A MAPS.ME user added 66 attractions [1] in a changeset that included
> Vancouver, Montreal and Vermont. While I visit Vancouver I'm not familiar
> with any of them. I left a changeset comment that has been replied to in the
> last 16 hours.
On Mon, 13 May 2019 at 03:50, Snusmumriken
wrote:
> On Sun, 2019-05-12 at 20:55 +0200, Tijmen Stam wrote:
> > It is not uncommon for key/values to be misnomers in OSM. Clearest
> > example is private-access ways being tagged as highway=* (plus
> > access=no) which is a misnomer in British English
On Sun, 12 May 2019 at 09:57, Jarek Piórkowski wrote:
> I can imagine calculating correct stop position being challenging in
> case of multi-lane bus stations like
> https://www.openstreetmap.org/way/37096072 (looks like
> https://en.wikipedia.org/wiki/File:Islington_TTC_B
On Sun, 12 May 2019 at 07:54, Tijmen Stam wrote:
> In my environment, some people are adding old ("razed" railways to
> openstreetmak, of which no trace is visible in the field.
> It concerns both old railways which have been gone since 1933, e.g.
> https://www.openstreetmap.org/way/592259029
On Thu, 9 May 2019 at 17:04, Markus wrote:
> Could you please give some examples where the stop position can't be
> calculated from the waiting area? I'd also like to know for which use
> cases the stop positions are necessary.
I can imagine calculating correct stop position being challenging in
s_stop to a highway with a path would that address the
> routing concerns? Or is that idea too simple?
>
> Thanks John
>
> On Tue, May 7, 2019, 3:53 PM Jarek Piórkowski, wrote:
>>
>> Sorry, crossed my wires while editing at one point:
>>
>> > 9a. Becau
Sorry, crossed my wires while editing at one point:
> 9a. Because we must retain hw=bus_stop per #3 and #5, any
> accommodation of these cases must either be initially of tags, or
> guidance on how to place highway=bus_stop tags
make that:
9a. Because we must retain hw=bus_stop per #3 and #5,
Hi all,
I wrote some point-form notes of the discussion so far for people to
refer or respond to. I asked questions in 7a, 7c, 8c, 10c, 11c, 13b,
14.
1. Majority of world's public transit is buses
2. Majority of world's bus stops are simple signs (or sometimes no
signs at all) and will never [1]
On Sun, 28 Apr 2019 at 10:04, Markus wrote:
> I've tested the bus routes from Stockholm in OsmAnd. They seem to work
> perfectly despite not having any public_transport=platform tags and
> public_transport=stop_position nodes.
Oh cool - with routing and time estimates and all?
> Tram stops
On Sat, 27 Apr 2019 at 10:35, Jarek Piórkowski wrote:
> ... it might make sense to check what they absolutely need and
> what is a nice to have. Do we know of any other major consumers of
> public transit relations?
Responding to myself, I remembered that of course Maps.me also doe
Hi all,
I noticed that OsmAnd has recently introduced support for some public
transit routing: https://osmand.net/blog/guideline-pt . Has anyone
used it or is familiar with the implementation? I would guess it would
make them one of the bigger consumers of public transit relations in
OSM and it
iki/Import/ODbL_Compatibility
--Jarek
On Tue, 23 Apr 2019 at 11:56, Joshua Kenney wrote:
>
> If I can obtain explicit permission from the city, would I still need to
> wait for the LWG approval?
>
> --Joshua
>
> On 2019-04-22 16:03, Jarek Piórkowski wrote:
> > Hi Joshua,
Hi Joshua,
Welcome to OSM, and thank you for your contributions!
To answer your first question: the non-building data sets (parks,
address points, bus stops, etc) are not currently importable without
further effort: we would have to get that exact licence (with text
including "City of Airdrie")
On Tue, 26 Mar 2019 at 13:10, Begin Daniel wrote:
> There is actually no standard “code” available since I use FME
> (www.safe.com). It is a proprietary ETL application and all operations are
> done using “transformers” (https://www.safe.com/transformers/). I can provide
> you with the
On Tue, 26 Mar 2019 at 11:58, Begin Daniel wrote:
> a first version of the cleaning tool is now functional.
>
> At this point, the tool is built to remove extra vertices, orthogonalize
> building footprints (when possible) and identify overlapped geometries.
> Details about the application are
Hi Martijn,
I am around tomorrow afternoon. Where roughly will you be? If you have
a Meeetup.com account you can also try sending a message in
https://www.meetup.com/OpenStreetMap-Toronto as some people there
might be interested as well!
(sending to the list so others now meetup group has been
On Fri, 15 Mar 2019 at 13:02, Nate Wessel wrote:
> Don't forget about the various alternative naming tags like alt_name=*,
> short_name=*, loc_name=*, and also name:etymology=* to make things absolutely
> clear.
>
> Having either spelling in one of these alternatives as appropriate would
>
Hi all,
A couple of months back we established a consensus [1] that "St." in
Canadian English city names should not be expanded.
I have been thinking of having the same for street names, and would
like to ask people's opinions.
My main motivation is St. Clair Avenue in Toronto. Every city
of Geography, PhD candidate in Urban Planning
> NateWessel.com
>
> On 3/14/19 7:42 PM, Jarek Piórkowski wrote:
>
> The changeset comment messages link to the Stats Canada import plan on
> the OSM wiki.
>
> I missed it but there were also some edits in Alberta
s no consensus on what is acceptable.
> After a request from a local group then I think that particular area can
> proceed.
>
> Quebec I think is being organised by Tim.
>
> Thanks John
>
> On Thu, 14 Mar 2019 at 18:56, Jarek Piórkowski wrote:
>>
>&
Are people aware that there are buildings being imported by
https://www.openstreetmap.org/user/huronavemapper (most recent 12
hours ago) and https://www.openstreetmap.org/user/hamptonavemapper
(most recent 5 days ago)?
I notice the wiki still says the import is on hold.
Thanks,
--Jarek
On Sun, 10 Mar 2019 at 17:28, Markus wrote:
> I still find service=siding to be inappropriate for irregular tracks
> and would prefer a new tag, such as usage=irregular. I am willing to
> prepare a proposal for it as soon as i find some time.
No worries, I agree a dedicated tag with proper
On Mon, 11 Feb 2019 at 11:33, Jarek Piórkowski wrote:
> In tram systems, some of the tracks might not be used regularly for
> passenger service. Some might be garage or work area tracks, and
> others might be used only for detours or emergency service.
> ...
> Plea
On Sun, 17 Feb 2019 at 13:43, Stephen Sprunk wrote:
>
> The current four service values are based on physical characteristics of the
> track that are easily observed on the ground and unlikely to change.
>
> This proposal seems to overload that with an indication of how the track is
> used, and
On Sun, 17 Feb 2019 at 10:55, Markus wrote:
> detour seems a bit unsuitable for turn tracks or connections because afaik it
> implies a longer route, but the tracks i have in mind are rather shortcuts.
> Maybe deviation doesn't have this meaning?
Right, I withdraw the detour suggestion.
On Sat, 16 Feb 2019 at 11:39, Markus wrote:
>
> Hi Jarek,
>
> I'd welcome a tag for tram tracks that normally aren't used except for
> diversions (in case of breakdowns, accidents, road/track works, events etc.)
> or for drives to the depot. However, i'm unsure whether service=siding is a
>
Hello,
In tram systems, some of the tracks might not be used regularly for
passenger service. Some might be garage or work area tracks, and
others might be used only for detours or emergency service.
The `service` key seems a natural match for tagging this, but its
values specified for railways
t; most likely to be already mapped. To a large degree, it's up the individual
> importer to do some quality control, review against existing object,
> satellite, etc. If we have specific issues we can and should address them,
> but if the data is largely good then I see no need to abort or revert.
&g
On Thu, 17 Jan 2019 at 21:46, OSM Volunteer stevea
wrote:
> Thanks, Jarek. Considering I am a proponent of "perfection must not be the
> enemy of good" (regarding OSM data entry), I think data which are "darn good,
> though not perfect" DO deserve to enter into OSM. Sometimes "darn good"
>
On Thu, 17 Jan 2019 at 21:04, OSM Volunteer stevea
wrote:
>> The import was discussed on talk-ca and in my opinion there was a consensus
>> of opinion it should go ahead. The data comes from the municipalities of
>> which there are some 37,000 separate ones in Canada. The idea of a single
>>
Yep, so in this case removing the name and keeping the ref on the
junction node sounds appropriate.
While we're at it, the service road
https://www.openstreetmap.org/way/48154169 doesn't seem to show up on
any of the current imagery in iD. Does it still exist?
--Jarek
On Mon, 5 Nov 2018 at
I have seen this used in Germany for "junction names", e.g.
https://www.openstreetmap.org/node/30249931 is one of the exits making
up "Frankfurter Kreuz" which is the major interchange near Frankfurt
and has its own (quite extensive) Wikipedia page:
https://de.wikipedia.org/wiki/Frankfurter_Kreuz
he code forward
means the direction in which the way is drawn in OpenStreetMap, while
backward means the opposite direction. "
On 14 July 2018 at 21:04, john whelan wrote:
> Fine but how does one decide which is forward?
>
> Thanks John
>
> On Sat, 14 Jul 2018, 3:02 pm Jarek Piórko
you likely want
https://wiki.openstreetmap.org/wiki/Forward_%26_backward,_left_%26_right
combined with https://wiki.openstreetmap.org/wiki/Key:cycleway
something like cycleway:forward=shared_lane, cycleway:backward=lane
On 14 July 2018 at 20:44, john whelan wrote:
> Ottawa has been adding these
Hi all,
Damien's question appears to be about nodes like
https://www.openstreetmap.org/node/438843513, which has
name=Berri-UQAM, operator=Société de transport de Montréal.
short_name=STM seems inappropriate here, we could do
operator:short_name=STM or something but it seems a bit much.
The
Hi,
Thanks for the feedback! It helps a lot to have information from real
world users.
I looked into the data briefly. The data that _has been_ entered in
OpenStreetMap looks correct. However, much data is not available.
A brief explanation of what is happening:
Postal codes are potentially
On 17 February 2018 at 00:03, OSM Volunteer stevea
<stevea...@softworkers.com> wrote:
> On Feb 16, 2018, at 2:56 PM, Jarek Piórkowski <ja...@piorkowski.ca> wrote:
>> With "street" in a street name, it's clear to most everyone that Pine St is
>> an abbrev
t Thomas, but a computer might have a bit
> of trouble there. And don't get me started on the absurdity that St is a
> contraction, not an abbreviation.
>
> I'm not going to rush out and change any existing tagging but I think this
> is one instance where rational thought needs to over
Hello,
First post here, sorry if I mess anything up!
A few months back I noticed that station names for Vancouver Skytrain
rapid transit system (all lines) are inconsistent: 32 of them have
"Station" in their name, but 23 don't, with little apparent pattern by
line or location.
Most of all I
70 matches
Mail list logo
