Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Jarek Piórkowski
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 tag speed limits, just look as
you're driving. Why map shorelines, just walk around til your feet get
wet. Why map bus stops, just look around you.

To give just one obvious counter-example: exact locations of shelters,
in particular of bus stop shelters, could be very useful for those
with visual disability (e.g. severe shortsightedness).

--Jarek

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


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Dave F via Talk-transit

If separate signs.poles - double nodes
if single sign/poles - two tags on one node

DaveF


On 13/05/2019 16:02, Johnparis wrote:

If a platform is multimodal, highway=bus_stop fails, because the same node
requires (for example) railway=tram_stop



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


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Dave F via Talk-transit

On 13/05/2019 16:36, Johnparis wrote:

the bus stop (platform) node allows for shelter=yes/no and bench=yes/no, so
it's not really necessary to separately map them and/or group them into the
stop area.


If you've the time, map them separately  - it makes the database more 
accurate, but I still fail to see why these items need to be collected 
together. If Philip really wants a router to tell him where the nearest 
shelter (surely you can just look around you), it is possible without 
relations as OSM has *always* been geospatially aware.


DaveF

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


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread DC Viennablog
Why does all the info need to be in one node and not on a way? Also, if there 
is a platform, it should be a polygon, not just a line. That should not be to 
micro to be mapped in true dimensions. If that object is the true only thing 
that defines the stop, it should be able to have the tags in every form (except 
multi-polygon relations)

The additional nodes make the confusing clutter!

KR
RobinD (emergency99)

Von: Johnparis 
Gesendet: Montag, 13. Mai 2019 17:38:36
An: Public transport/transit/shared taxi related topics
Betreff: Re: [Talk-transit] Ideas for a simplified public transportation scheme

I agree that platforms should be mapped as ways only if they physically exist. 
What I'm saying is that I don't object if someone does map such an object, but 
the information from the transit agency should always be contained in a node, 
not a way, as Jo mentioned.

I usually place the node inside the closed way if it exists, but another 
possibility (and necessary if it's an unclosed way) is to make the node a part 
of the way.



On Mon, May 13, 2019 at 5:36 PM Dave F via Talk-transit 
mailto:talk-transit@openstreetmap.org>> wrote:
On 13/05/2019 16:14, Johnparis wrote:
> I don't have any particular problem with mapping an area (closed way) or a
> way (line segment) as a platform,

Please, please only map a platform /if/ it's a physical structure.
Imaginary meta-objects  don't work in OSM

DaveF

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


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Dave F via Talk-transit
I think this highlights another PT schema problem - expecting too much 
from a routing engine.


On 13/05/2019 16:29, Philip Barnes wrote:


I do, but there tend to be lots of bus stops and sometimes I want it to choose 
the one with the shelter if its only a short extra walk.

Phil (trigpoint)




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


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Johnparis
I agree that platforms should be mapped as ways only if they physically
exist. What I'm saying is that I don't object if someone does map such an
object, but the information from the transit agency should always be
contained in a node, not a way, as Jo mentioned.

I usually place the node inside the closed way if it exists, but another
possibility (and necessary if it's an unclosed way) is to make the node a
part of the way.



On Mon, May 13, 2019 at 5:36 PM Dave F via Talk-transit <
talk-transit@openstreetmap.org> wrote:

> On 13/05/2019 16:14, Johnparis wrote:
> > I don't have any particular problem with mapping an area (closed way) or
> a
> > way (line segment) as a platform,
>
> Please, please only map a platform /if/ it's a physical structure.
> Imaginary meta-objects  don't work in OSM
>
> DaveF
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread DC Viennablog
When the platform is a really existing built thing, you would need 
highway=platform on it, and an additional highway=bus_stop at the stop pole or 
wherever. That is more clutter and worse state of the database, than if we 
would finally move to the more versatile public_transport=platform. As it is 
the only thing that the p_t:v2 scheme actually needs anyway, we could save so 
much node clutter if we would use only that.

The stop (bus, tram, whatever) is only a pin in a field? Ok, let‘s have a 
node(p_t=platform;name=*) and put only that in the route relations.

The stop has a piece of sidewalk that is built forward slightly or a true 
platform: Have a polygon with the same tags.

As usually, any mode of transport is longer and and have multiple doors, you 
can still have the polygon as saying „anywhere here, the passengers can wait“.

Why is it so bad to adapt to a scheme that got voted in favour of long ago?

Ok, some additional confusing clutter exists in this scheme, but if I 
understand the explanations here, most, if not all of that is not required.

If the render would finally render public_transport=platform nodes exactly like 
highway=bus_stop / any tram/train stop equivalent, and 
public_transport=platform polygons exactly like highway=platform, and we would 
use only that, the state of the database would be far better than the simply 
not versatile enough bus stop node.

Maybe we could at some point get to just usefully rewrite the v2 scheme 
definition to make it easier to understand. Most dislike against it seems to 
come from not understanding it correctly, as it is described to complex in some 
cases.

If we were to say, that only p_t=platform is to be used in most cases, on nodes 
or ways beside the road, and nothing else is actually required, it be more 
accessible than hw=bus_stop=platform, the relations would be almost the same 
as now, and the only thing that needs to be slightly corrected be the renders 
to finally also accept this.

Except for being older, what makes hw=bus_stop better?
You still might have to then use hw=platform and maybe p_t=platform 
additionally, it needs to be an extra node, it does not necessarily mean what 
it says (bus stop is conceptually a combination of platform and stop 
position[s]) and it is a stiff node, that only works for buses then.

What will it take for the haters to accept this (potentially) simpler, newer 
scheme?

KR
RobinD (emergency99)

Von: Dave F via Talk-transit 
Gesendet: Montag, 13. Mai 2019 17:10:21
An: talk-transit@openstreetmap.org
Cc: Dave F
Betreff: Re: [Talk-transit] Ideas for a simplified public transportation scheme

On 13/05/2019 07:36, Tijmen Stam wrote:
> On 13-05-19 00:14, Jo wrote:
>> I like to keep things simple, the best way to accomplish that, is by
>> having a single object for each stop that holds all the details for
>> its "lifetime". That's why I don't like the idea of 'upgrading from a
>> node to a way/area or a relation.
>
> I don't agree with you on that point. With that view we can't change
> things in OSM anymore to a more precise mapping.

A bus stop as a node to represent the sign/pole is /far/ more accurate
than an arbitrary invisible mutli-noded polygon.

DaveF

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


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Johnparis
the bus stop (platform) node allows for shelter=yes/no and bench=yes/no, so
it's not really necessary to separately map them and/or group them into the
stop area.


On Mon, May 13, 2019 at 5:30 PM Philip Barnes  wrote:

> On Monday, 13 May 2019, Dave F via Talk-transit wrote:
> >
> >
> > On 13/05/2019 16:14, Philip Barnes wrote:
> > >
> > > I can see that when its raining I may want the router to direct me to
> a stop with a shelter rather than stand in the rain.
> > Surely you need to be given the bus stop which will take you to your
> > destination? That /is/ the point of a router.
> >
> I do, but there tend to be lots of bus stops and sometimes I want it to
> choose the one with the shelter if its only a short extra walk.
>
> Phil (trigpoint)
>
> --
> Sent from my Sailfish device
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Dave F via Talk-transit

On 13/05/2019 16:14, Johnparis wrote:

I don't have any particular problem with mapping an area (closed way) or a
way (line segment) as a platform,


Please, please only map a platform /if/ it's a physical structure. 
Imaginary meta-objects  don't work in OSM


DaveF

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


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Philip Barnes
On Monday, 13 May 2019, Dave F via Talk-transit wrote:
> 
> 
> On 13/05/2019 16:14, Philip Barnes wrote:
> >
> > I can see that when its raining I may want the router to direct me to a 
> > stop with a shelter rather than stand in the rain.
> Surely you need to be given the bus stop which will take you to your 
> destination? That /is/ the point of a router.
> 
I do, but there tend to be lots of bus stops and sometimes I want it to choose 
the one with the shelter if its only a short extra walk.

Phil (trigpoint)

-- 
Sent from my Sailfish device
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Dave F via Talk-transit



On 13/05/2019 16:14, Philip Barnes wrote:


I can see that when its raining I may want the router to direct me to a stop 
with a shelter rather than stand in the rain.
Surely you need to be given the bus stop which will take you to your 
destination? That /is/ the point of a router.


DaveF

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


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Philip Barnes
On Monday, 13 May 2019, Dave F via Talk-transit wrote:
> 
> 
> On 12/05/2019 23:14, Jo wrote:
> > About the stop_area relations, they're not needed everywhere, but they
> > could be used to show what belongs together. Of course, that would mean all
> > the objects related to the stop at one side of the street, not both sides.
> 
> Why items "belong together"?
> Does a router need to know there's a shelter, benches, litter bind etc?
> 
I can see that when its raining I may want the router to direct me to a stop 
with a shelter rather than stand in the rain. Shelters tend to have lean on 
seating.

Otherwise benches and bins may be nearby but they are not exclusively 
associated with buses. A bin is not provided by a bus company and is not fir 
the exclusive use of bus passengers.

Phil (trigpoint)

-- 
Sent from my Sailfish device
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Johnparis
I don't have any particular problem with mapping an area (closed way) or a
way (line segment) as a platform, but I agree with Jo that the information
should be contained in a node. That node can be part of the way. From
experience, it complicates things quite a bit when you transfer the
information from the node to the way.


On Mon, May 13, 2019 at 5:10 PM Dave F via Talk-transit <
talk-transit@openstreetmap.org> wrote:

> On 13/05/2019 07:36, Tijmen Stam wrote:
> > On 13-05-19 00:14, Jo wrote:
> >> I like to keep things simple, the best way to accomplish that, is by
> >> having a single object for each stop that holds all the details for
> >> its "lifetime". That's why I don't like the idea of 'upgrading from a
> >> node to a way/area or a relation.
> >
> > I don't agree with you on that point. With that view we can't change
> > things in OSM anymore to a more precise mapping.
>
> A bus stop as a node to represent the sign/pole is /far/ more accurate
> than an arbitrary invisible mutli-noded polygon.
>
> DaveF
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Johnparis
Definitely not non-transit items.

GTFS defines the equivalent of a stop area. The Paris regional transit
agency largely reflects these as transfer points between lines of different
bus companies. It can also be useful to link a stop position to a platform,
which can be very useful when it's not clear which street the platform is
facing.

A stop area in Paris, for example, might be Gare Saint-Lazare, which would
group (a) the many bus stops (platforms) named "Gare Saint-Lazare" in the
neighborhood, (b) possibly any associated stop positions for those bus
platforms, (c) the metro lines with Gare Saint-Lazare stations, the
platforms of which differ, (d) the regional train lines that terminate at
Gare Saint-Lazare, (e) any intercity trains that go there.

In general I don't use them.

On Mon, May 13, 2019 at 5:03 PM Dave F via Talk-transit <
talk-transit@openstreetmap.org> wrote:

>
>
> On 12/05/2019 23:14, Jo wrote:
> > About the stop_area relations, they're not needed everywhere, but they
> > could be used to show what belongs together. Of course, that would mean
> all
> > the objects related to the stop at one side of the street, not both
> sides.
>
> Why items "belong together"?
> Does a router need to know there's a shelter, benches, litter bind etc?
>
>
> DaveF
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Dave F via Talk-transit

On 13/05/2019 07:36, Tijmen Stam wrote:

On 13-05-19 00:14, Jo wrote:
I like to keep things simple, the best way to accomplish that, is by 
having a single object for each stop that holds all the details for 
its "lifetime". That's why I don't like the idea of 'upgrading from a 
node to a way/area or a relation.


I don't agree with you on that point. With that view we can't change 
things in OSM anymore to a more precise mapping.


A bus stop as a node to represent the sign/pole is /far/ more accurate 
than an arbitrary invisible mutli-noded polygon.


DaveF

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


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Dave F via Talk-transit



On 12/05/2019 23:14, Jo wrote:

About the stop_area relations, they're not needed everywhere, but they
could be used to show what belongs together. Of course, that would mean all
the objects related to the stop at one side of the street, not both sides.


Why items "belong together"?
Does a router need to know there's a shelter, benches, litter bind etc?


DaveF

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


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Johnparis
If a platform is multimodal, highway=bus_stop fails, because the same node
requires (for example) railway=tram_stop



On Mon, May 13, 2019 at 4:56 PM Dave F via Talk-transit <
talk-transit@openstreetmap.org> wrote:

> On 12/05/2019 19:55, Tijmen Stam wrote:
> .
> >
> > No, changing of tagging, not replication.
> > There is no need to map with highway=bus_stop anymore (save for
> > rendering on osm_carto)
>
> No. highway=bus_stop is fully relevant as the day it was first used.
> It's simple, clear, comprehensible meaning far out ways the supposedly
> "overwhelming" PT tagging which few mappers have adopted. This thread
> wouldn't have happened it is was popular. It appears dead in the water.
>
> Show me how p_t=platform adds anything to the quality of the OSM
> database over highway=bus_stop.
>
> DaveF
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Dave F via Talk-transit

On 12/05/2019 19:55, Tijmen Stam wrote:
.


No, changing of tagging, not replication.
There is no need to map with highway=bus_stop anymore (save for 
rendering on osm_carto)


No. highway=bus_stop is fully relevant as the day it was first used. 
It's simple, clear, comprehensible meaning far out ways the supposedly 
"overwhelming" PT tagging which few mappers have adopted. This thread 
wouldn't have happened it is was popular. It appears dead in the water.


Show me how p_t=platform adds anything to the quality of the OSM 
database over highway=bus_stop.


DaveF

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


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Snusmumriken
On Mon, 2019-05-13 at 08:47 -0400, Jarek Piórkowski wrote:
> 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 (which we use)
> > 
> > Misnomers should clearly be avoided if at all possible. And here it
> > is
> > quite possible, by calling a bus stop a bus stop.
> 
> Calling a bus stop a bus stop is fine, but if we want to avoid
> misnomers, why is it under the "highway" category, along with
> expressways and speed bumps and toll gantries, and not a "public
> transport" category?

Good point. If we would start from scratch them perhaps
public_transport=bus_stop would be the logical tag. But in OSM we
usually don't do renaming of established tags. And at least the value
part is correct in the key-value pair, at that is the one most
important to get right. And the highway-key isn't really that much off.


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


[Talk-transit] "more then one platform in one location"

2019-05-13 Thread Dave F via Talk-transit

Hi

On the railway=platform wiki page there's a comment:

"If there are more then one platform in one location, a relation could 
be used to "bind" them together. See Approved Public Transport Schema 
 
for more information."



What does the "more then one platform in one location" mean? Are there 
examples?


Cheers
DaveF.
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Jarek Piórkowski
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 (which we use)
>
> Misnomers should clearly be avoided if at all possible. And here it is
> quite possible, by calling a bus stop a bus stop.

Calling a bus stop a bus stop is fine, but if we want to avoid
misnomers, why is it under the "highway" category, along with
expressways and speed bumps and toll gantries, and not a "public
transport" category?

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


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Jo
Indeed, that's were we don't seem to be able to agree.

Let's say all bus stops are mapped on nodes to get started.

Then a mapper notices there is a platform near to some of them. Those
platforms can simply be drawn, in addition, to the nodes that represent
such stops. No need to transfer from a node to a way and update all the
route relations where that stop is used.

If I'm not mistaken, in the Netherlands, all house numbers are mapped on
nodes, which are contained within building outlines. I don't really like
that a spatial query is needed to connect buildings to addresses, but as
far as 'tranquility' in the data goes, it's a nice solution.

Back to PT. What most data consumers need is to know where can I
board/alight from the vehicles. A set of coordinates near to where the bus
passes + an indication on which side of the street the doors will open.

For drawing maps we need that + an overview of the itineraries, i.e. the
ways the bus passes on.

For routing we basically only need the stops in the right order +
timetables that come from elsewhere. But it's nice to have the coordinates
of the stops directly available.

Polyglot

Polyglot



On Mon, May 13, 2019 at 8:36 AM Tijmen Stam  wrote:

> On 13-05-19 00:14, Jo wrote:
> > I like to keep things simple, the best way to accomplish that, is by
> > having a single object for each stop that holds all the details for its
> > "lifetime". That's why I don't like the idea of 'upgrading from a node
> > to a way/area or a relation.
>
> I don't agree with you on that point. With that view we can't change
> things in OSM anymore to a more precise mapping.
>
> IMHO it shouldn't be the internal OSM database ID that makes something a
> "logical object", but the ref on that object.
> Say you're transitioning from a node to a way for a bus stop, simply
> copy the relevant tags from that node to the way.
>
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Snusmumriken
On Sun, 2019-05-12 at 20:55 +0200, Tijmen Stam wrote:
> a "public_transport=platform" is not defined as being "platform"
> (raised good concrete flooring) but as "the place where people wait
> to board a bus/tram/train". Whatever form that is.
> 
> 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 (which we use)

Misnomers should clearly be avoided if at all possible. And here it is
quite possible, by calling a bus stop a bus stop.




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


Re: [Talk-transit] Ideas for a simplified public transportation scheme

2019-05-13 Thread Tijmen Stam

On 13-05-19 00:14, Jo wrote:
I like to keep things simple, the best way to accomplish that, is by 
having a single object for each stop that holds all the details for its 
"lifetime". That's why I don't like the idea of 'upgrading from a node 
to a way/area or a relation.


I don't agree with you on that point. With that view we can't change 
things in OSM anymore to a more precise mapping.


IMHO it shouldn't be the internal OSM database ID that makes something a 
"logical object", but the ref on that object.
Say you're transitioning from a node to a way for a bus stop, simply 
copy the relevant tags from that node to the way.



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


Re: [Talk-transit] Old railways

2019-05-13 Thread Tijmen Stam

On 13-05-19 01:33, Mike N wrote:

On 5/12/2019 1:45 PM, Tijmen Stam wrote:
Btw, do you know of a way to copy data from one layer in JOSM to 
another, while keeping it at the exact same position?


Edit / Paste at Source Position (CTRL+ALT+V).


Thank you (and John Whelan)


I still wish it was easier to migrate objects to Open Historical Map.


The method I used yesterday was
1. download from OSM (or Overpass Turbo) into JOSM
2. Copy wanted data to new layer
3. edit (if necessary)
4. change api in JOSM
5. upload

  While I also don't think that Razed railways without a trace no longer 
belong in OSM, there's a bit of tradition that allowed them here.  Since 
they don't render on the default OSM site, I leave the old tracks for now.


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



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