Re: [Tagging] tagging laboratories

2019-03-04 Thread Volker Schmidt
... and then there are big research centres that are called "laboratory".
Like LLNL or Los Alamos National Laboratory.

On Tue, 5 Mar 2019, 06:08 Kevin,  wrote:

> In general at my university we usually talk about "wet labs" vs "dry
> labs", mostly in regards to hazardous materials.
>
> https://en.wikipedia.org/wiki/Wet_lab
>
> And for wet labs, there are different levels for biosafety...
>
> https://en.wikipedia.org/wiki/Biosafety_level
>
>
>
>
>
>
> On Mon, Mar 4, 2019 at 10:04 PM Warin <61sundow...@gmail.com> wrote:
>
>> On 04/03/19 21:25, Martin Koppenhoefer wrote:
>>
>>
>> Am Mo., 4. März 2019 um 09:37 Uhr schrieb Warin <61sundow...@gmail.com>:
>>
>>>
>>>
>>> These can be commercialfirms, part of the government, or part of a
>>> university etc.
>>>
>>> They usually specialise in one field so will need sub tags.
>>
>>
>>
>>
>> I would question whether we put all kind of "laboratory" into the same
>> category and distinguish them by subtags. There are too many different kind
>> of things that could be subsummized as "laboratory". Think about eletronic
>> laboratories, chemistry research labs, biochemical labs, labs for human
>> healtcare analytics, etc.
>> First distinction could be "research lab" vs. "analytical lab" vs. maybe
>> more types, and these should IMHO become main tags, not subtags.
>>
>> There is also some potential confusion with the word "laboratory" being
>> used as a hyped name for workspace where you would not expect it, e.g.
>> software laboratory, architectural design laboratory, art laboratory, etc.
>> So we would need some definition, what the criterion for "laboratory" is
>> (or is it the name?).
>>
>>
>> To me a true 'laboratory' has controlled environmental conditions,
>> usually temperature is tightly controlled, the better labs have humidity
>> control probably not as tight.
>> They may have other things controlled too - such as radio interference,
>> dust.
>>
>> A software, art or architectural design laboratory would not meet these
>> conditions. The key being that the control is tighter (narrower)
>> environmental control than, say for example, an office environment.
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] tagging laboratories

2019-03-04 Thread Kevin
In general at my university we usually talk about "wet labs" vs "dry labs",
mostly in regards to hazardous materials.

https://en.wikipedia.org/wiki/Wet_lab

And for wet labs, there are different levels for biosafety...

https://en.wikipedia.org/wiki/Biosafety_level






On Mon, Mar 4, 2019 at 10:04 PM Warin <61sundow...@gmail.com> wrote:

> On 04/03/19 21:25, Martin Koppenhoefer wrote:
>
>
> Am Mo., 4. März 2019 um 09:37 Uhr schrieb Warin <61sundow...@gmail.com>:
>
>>
>>
>> These can be commercialfirms, part of the government, or part of a
>> university etc.
>>
>> They usually specialise in one field so will need sub tags.
>
>
>
>
> I would question whether we put all kind of "laboratory" into the same
> category and distinguish them by subtags. There are too many different kind
> of things that could be subsummized as "laboratory". Think about eletronic
> laboratories, chemistry research labs, biochemical labs, labs for human
> healtcare analytics, etc.
> First distinction could be "research lab" vs. "analytical lab" vs. maybe
> more types, and these should IMHO become main tags, not subtags.
>
> There is also some potential confusion with the word "laboratory" being
> used as a hyped name for workspace where you would not expect it, e.g.
> software laboratory, architectural design laboratory, art laboratory, etc.
> So we would need some definition, what the criterion for "laboratory" is
> (or is it the name?).
>
>
> To me a true 'laboratory' has controlled environmental conditions, usually
> temperature is tightly controlled, the better labs have humidity control
> probably not as tight.
> They may have other things controlled too - such as radio interference,
> dust.
>
> A software, art or architectural design laboratory would not meet these
> conditions. The key being that the control is tighter (narrower)
> environmental control than, say for example, an office environment.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] tagging laboratories

2019-03-04 Thread Warin

On 04/03/19 21:25, Martin Koppenhoefer wrote:


Am Mo., 4. März 2019 um 09:37 Uhr schrieb Warin <61sundow...@gmail.com 
>:




These can be commercialfirms, part of the government, or part of a
university etc.

They usually specialise in one field so will need sub tags.




I would question whether we put all kind of "laboratory" into the same 
category and distinguish them by subtags. There are too many different 
kind of things that could be subsummized as "laboratory". Think about 
eletronic laboratories, chemistry research labs, biochemical labs, 
labs for human healtcare analytics, etc.
First distinction could be "research lab" vs. "analytical lab" vs. 
maybe more types, and these should IMHO become main tags, not subtags.


There is also some potential confusion with the word "laboratory" 
being used as a hyped name for workspace where you would not expect 
it, e.g. software laboratory, architectural design laboratory, art 
laboratory, etc.
So we would need some definition, what the criterion for "laboratory" 
is (or is it the name?).


To me a true 'laboratory' has controlled environmental conditions, 
usually temperature is tightly controlled, the better labs have humidity 
control probably not as tight.
They may have other things controlled too - such as radio interference, 
dust.


A software, art or architectural design laboratory would not meet these 
conditions. The key being that the control is tighter (narrower) 
environmental control than, say for example, an office environment.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] New Tag "Departures" voting results.

2019-03-04 Thread Jarek Piórkowski
Hello,

I've gotten paid for wrangling GTFS worldwide before - happy to tell
you some of my experiences.

On Sat, 2 Mar 2019 at 19:42, Paul Allen  wrote:
> As I said, I'd prefer not to use url=* because it could be for anything - a 
> page about the history of
> the bus stop (maybe the shelter is a listed building),

That would rather be website=* though. And to keep it simple, you can
do a lot worse than putting an "upcoming buses from this stop" page
URL into the website=* for vast majority of stops out there. Only
problem is that doesn't scale very nicely to 1 stops.

> or a timetable or whatever web page the
> mapper happened to think relevant.  I'd prefer to distinguish between a 
> human-readable timetable
> and raw GTFS data (not really human-readable but could be parsed by an app).  
> For lack of anything
> better, I'd be happy with timetable=* and gtfs=* but I expect somebody will 
> be along shortly to explain
> why those are a very bad idea.

I'd be happy with gtfs= on a possibly high-level
relation that ultimately includes stops, and timetable= or
departures= on stops where available as HTML page.

I think the Berlin tagging makes sense:
https://osm.org/node/1137469153 with website=http://qr.bvg.de/h309003.
Other pages I'm familiar with are
https://nb.translink.ca/text/stop/50167 or
http://m.ttc.ca/Schedule/m-schedule.jsp?Route=63N=n.b._on_Shaw_St_at_King_St_West_North_Side=timed

From Canadian English perspective, "timetable" would be more likely to
be interpreted as all departures for the whole week (as on the TTC
page). "departures" matches the "next 3 buses" case a bit closer. But
perhaps it's different in British English.

> Whatever we go for, we have to cater to the fact that a particular route may 
> have more than one
> operator (I'm not talking about super-routes here).  Around here there are 
> many small local operators,
> and longer routes sometimes split the service between two operators (i.e., 
> the route X to Y might
> be split between an operator based in X and another operator based in Y).

GTFS as a format is operator agnostic (the operator information is not
in the data at all, only "agency", but each route must be tied to
exactly one agency). It is more of a question whether a full timetable
is provided in a given GTFS file or if it is a partial timetable and
we want to support merging timetables.

Having done some work on merging GTFS, I am afraid the latter is a
deep rabbit hole very few data consumers will go down.

What I have seen in transit data collection is one physical stop
served by multiple agencies which provide separate GTFS files, and
sometimes they reference the stop using different stop IDs. But in
that case it would be using different routes, and it should be doable
with ref:=123 + ref:=abc (where agency_1 and
agency_2 preferably match the GTFS agency IDs...)

Feel free to ask for more technical info about GTFS :) Or for
real-world usage - I've looked at GTFS for most major metros in Canada
and U.S., some smaller metros, data where available in Europe, and a
bit of Australia.

> But stops can be used by
> more than one route.  So then we'd need timetable:route-number:operator=link.

Different route operators with separate timetables is probably in the
"use departures_1 for departures that don't fit" territory. We don't
need to support every edge case to be useful, just the majority of
real world use.

--Jarek

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

2019-03-04 Thread Clifford Snow
For anyone interested in listening to Lou Huang's talk, I found it on
Youtube. It starts at about 42:00 and ends at 48:00

[1] https://www.youtube.com/watch?v=xOGsy9BFJ5Y

On Mon, Mar 4, 2019 at 4:02 PM Nick Bolten  wrote:

> > Can we please first define a solution (e.g. a relation) for connecting
> such separately mapped components of a road to the highway?
>
> I agree, this is a very important issue and it happens for a lot of
> different situations - a lot of different features that can and are mapped
> separately would benefit from a street <-> separate feature mapping. This
> is the incentive behind mapping streets, auto lanes, bus lanes, bicycle
> lanes, sidewalks, verges, etc. on the street: the relationship query is
> unnecessary, the information is shared in the way.
>
> Stable IDs would help with this problem, but I haven't seen much traction
> behind adding core features to data types. What would you think of a new
> 'associatedStreet'-style relation that would organize the various features
> that should be associated between streets and the surrounding environment?
> Example members (with no particular naming/role conventions in mind):
>
> - The street way(s).
> - Any separate bicycle way(s).
> - Left sidewalk way(s)
> - Right sidewalk way(s)
> - Left curb(s)
> - Right curb(s)
>
> Other info that *might* benefit from either this or a similar relation:
> - Building(s) / addresses (as France does)
> - Greenways (trees / tree lines / verges)
> - Traffic islands (a common use case for barrier=kerb ways
> - Some street signs (some should probably be in a different relation
> involving more than one way)
>
> This is certainly a lot of members, and not all are necessary, but I think
> there's value in traversing between these data in, as you mention, a
> machine-readable way.
>
> > This fundamental limitation really needs to be addressed before we
> consider splitting roads into even more parallel ways.
>
> Just to clarify, the road can keep all of its same data as is currently
> mapped. This would be an additional piece of information that tends to go
> unmapped.
>
> Best,
>
> Nick
>
> On Mon, Mar 4, 2019 at 12:05 PM Tobias Knerr  wrote:
>
>> On 03.03.19 20:12, Nick Bolten wrote:
>> > I wanted to get a discussion started to see what people think of
>> > mapping curbs as ways.
>>
>> Can we please first define a solution (e.g. a relation) for connecting
>> such separately mapped components of a road to the highway?
>>
>> Painting lines next to each other fails to express the important
>> information that this kerb/sidewalk/cycleway is part of that highway
>> over there. Such missing information may be easily guessed by a human
>> viewer, but it's currently not available in a machine-readable form.
>>
>> This fundamental limitation really needs to be addressed before we
>> consider splitting roads into even more parallel ways.
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

2019-03-04 Thread Nick Bolten
> Can we please first define a solution (e.g. a relation) for connecting
such separately mapped components of a road to the highway?

I agree, this is a very important issue and it happens for a lot of
different situations - a lot of different features that can and are mapped
separately would benefit from a street <-> separate feature mapping. This
is the incentive behind mapping streets, auto lanes, bus lanes, bicycle
lanes, sidewalks, verges, etc. on the street: the relationship query is
unnecessary, the information is shared in the way.

Stable IDs would help with this problem, but I haven't seen much traction
behind adding core features to data types. What would you think of a new
'associatedStreet'-style relation that would organize the various features
that should be associated between streets and the surrounding environment?
Example members (with no particular naming/role conventions in mind):

- The street way(s).
- Any separate bicycle way(s).
- Left sidewalk way(s)
- Right sidewalk way(s)
- Left curb(s)
- Right curb(s)

Other info that *might* benefit from either this or a similar relation:
- Building(s) / addresses (as France does)
- Greenways (trees / tree lines / verges)
- Traffic islands (a common use case for barrier=kerb ways
- Some street signs (some should probably be in a different relation
involving more than one way)

This is certainly a lot of members, and not all are necessary, but I think
there's value in traversing between these data in, as you mention, a
machine-readable way.

> This fundamental limitation really needs to be addressed before we
consider splitting roads into even more parallel ways.

Just to clarify, the road can keep all of its same data as is currently
mapped. This would be an additional piece of information that tends to go
unmapped.

Best,

Nick

On Mon, Mar 4, 2019 at 12:05 PM Tobias Knerr  wrote:

> On 03.03.19 20:12, Nick Bolten wrote:
> > I wanted to get a discussion started to see what people think of
> > mapping curbs as ways.
>
> Can we please first define a solution (e.g. a relation) for connecting
> such separately mapped components of a road to the highway?
>
> Painting lines next to each other fails to express the important
> information that this kerb/sidewalk/cycleway is part of that highway
> over there. Such missing information may be easily guessed by a human
> viewer, but it's currently not available in a machine-readable form.
>
> This fundamental limitation really needs to be addressed before we
> consider splitting roads into even more parallel ways.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

2019-03-04 Thread Clifford Snow
I recall seeing a lightning talk at the 2016 State of the Map US in Seattle
about mapping curb lines. Lou Huang gave a talk "Representing streets in
OSM with Curblines" [1] which proposed mapping streets from curb to curb as
polygons if I recall correctly. (Unfortunately I couldn't find a video of
his talk.)  His proposal overcomes some of the problems of mapping curb
lines as a separate way. But the level of detail required to map as a
polygon seems to be a real barrier to acceptance.

When I originally mapped sidewalks and footways in my small town, I added
the sidewalk=left/right/both/no tag to the street. Having just gone back to
actually map each sidewalk, having the information was helpful. But keeping
two sets of basically identical sets of information doesn't make sense. If
we add in a third linestring for the curb line, do we end up with three
sets of similar info?

Adding curb info to streets to me doesn't make much sense because streets
are longer than the curb. Adding curb info to sidewalks won't help vehicle
traffic  where it's nice to know if there is a curb.

The only logical option is to map curbs as independent ways even if it
means we might have three sets of similar information. To develop a
proposal on how to map sidewalks, curbs, and streets should be done before
we jump in to import the data. Much like Nick and UW did with the proposal
to map sidewalks as independent ways.

I know cities collect curb information. Even my small town does. The data
is there and if it's properly licensed, it could be useful in OSM.

[1] https://2016.stateofthemap.us/project-lead/

Clifford

-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

2019-03-04 Thread Nick Bolten
I'm also a fan of the dedicated line, my primary interest being pedestrian
accessibility + QA-ability of such data.

I keep thinking, "hey, I'll go map a curb line!" and run into a related
issue: I can definitely map barrier=kerb and kerb=raised when one of those
exists along a path - could be near a sidewalk, could be a traffic island,
etc. But would it be an oxymoron to map barrier=kerb and kerb=flush (or
kerb=lowered)? I don't think I would call that a barrier. However, it is
definitely what happens to the curb along most city blocks - transitions
from raised to lowered to flush to rolled. I would find it much more useful
to know the curb state along a continuing line (set of ways) than to see a
bunch of disconnected kerb=raised lines or a kerb=raised line with kerb=*
nodes indicating a change (particularly since direction is ambiguous for a
node).

All of this is to say, what would you think of a way that only had
kerb=lowered? Should there be a barrier=kerb tag there? Or *=kerb?

Best,

Nick

On Mon, Mar 4, 2019 at 8:44 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 4. Mar 2019, at 17:28, Nick Bolten  wrote:
> >
> > Putting aside the preexistence of barrier=kerb + kerb=* on lines, do you
> mean we should put kerb=* on a sidewalk line, a road line, or both?
>
>
> I would prefer a dedicated way for the kerb, and would not tag it on the
> road highway. Also using a node at the intersection of the kerb with the
> crossing footway/cycleway (at crossings) seems safe.
> Eventually it could be considered adding kerb information on a sidewalk
> way (as the lesser evil).
> On a road way the resulting fragmentation would be undesirable and the
> kerb information belongs more to the sidewalk than to the road way (IMHO).
>
> Cheers, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "satellit"

2019-03-04 Thread Warin

On 04/03/19 21:54, Martin Koppenhoefer wrote:
I would expect the "uplink" information to be relevant, as most 
satellite antennas are used for receiving only (those private tv 
reception antennas).
Do not counter this with "not sufficiently relevant for mapping", as 
you'll see people will likely tag it ;-)


Subtagging (or a property) seems better for the "uplink" information, 
because it doesn't require people to know the details in order to map 
something, I agree.





+1 to having uplink/downlink' as a sub tag. Actually I think Tx/Rx 
(transmit/receive/transceiver) are better as that can be used on 
terrestrial antennas and has more detail. And yes these would need some 
knowledge to tag correctly for some installations. These can be seen as 
a property of the antenna, But I would not use the words 'type', 
'property',



The disk is technically not the antenna, it is a reflector.

See https://wiki.openstreetmap.org/wiki/Proposed_features/antenna:use 
for a proposed collection of tags


 * antenna:application =
   
mobile_phone/broadcast_radio/broadcast_television/citizens_band/amateur_radio/radar/*
   to state the application of an antenna’s signal is put.

 * antenna:propagation =reception/transmission/two_way to denote the
   direction of the signal.

 * antenna:configuration =
   monopole/dipole/yagi/log_periodic/horn/curtain/helical/phased_array/loop/*
   To state the antenna configuration.

 * antenna:polarisation = vertical/horizontal/dual/circular/* to denote
   the signal polarisation.

 * antenna:reflector = dish/wire_element/wire_screen/* To state the
   antennas reflector – if it has one.

 * antenna:cover = radome/* To state the antennas protective cover – if
   it has one.






___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

2019-03-04 Thread Tobias Knerr
On 03.03.19 20:12, Nick Bolten wrote:
> I wanted to get a discussion started to see what people think of
> mapping curbs as ways.

Can we please first define a solution (e.g. a relation) for connecting
such separately mapped components of a road to the highway?

Painting lines next to each other fails to express the important
information that this kerb/sidewalk/cycleway is part of that highway
over there. Such missing information may be easily guessed by a human
viewer, but it's currently not available in a machine-readable form.

This fundamental limitation really needs to be addressed before we
consider splitting roads into even more parallel ways.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

2019-03-04 Thread Martin Koppenhoefer


sent from a phone

> On 4. Mar 2019, at 17:28, Nick Bolten  wrote:
> 
> Putting aside the preexistence of barrier=kerb + kerb=* on lines, do you mean 
> we should put kerb=* on a sidewalk line, a road line, or both?


I would prefer a dedicated way for the kerb, and would not tag it on the road 
highway. Also using a node at the intersection of the kerb with the crossing 
footway/cycleway (at crossings) seems safe. 
Eventually it could be considered adding kerb information on a sidewalk way (as 
the lesser evil). 
On a road way the resulting fragmentation would be undesirable and the kerb 
information belongs more to the sidewalk than to the road way (IMHO).

Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

2019-03-04 Thread Nick Bolten
More detail means more information and barrier=kerb on ways has existed for
about a decade. I'm interested in hearing pros and cons of different
strategies, if anyone is interested.

On Mon, Mar 4, 2019 at 6:32 AM yo paseopor  wrote:

> It is the same story again and again.
>
> -First was the node and ways. And some classification . It was not enough
> -Second arrived relations. but when you want to specify more..it is not
> enough
> -Then it was other tags like classification, lanes, sidewalks...  it is
> not enough if you want to make all the details.
> -Then arrived the area mapping to make it more realistic. But only for
> some items as sidewalks.
> Congrats , now we need the detail of a kerb drawed as an area.
>
> I think best way at first is using the same tagging we have for kerb
> https://wiki.openstreetmap.org/wiki/Key:kerb
> https://taginfo.openstreetmap.org/search?q=kerb#keys
>
> Then...you know you will need more tags...cuz it is not enough ;)
> PD: don't map for the render (instead it would be OSM official's one). All
> real info is welcomed
>
> Salut i mapes
> yopaseopor
>
> On Sun, Mar 3, 2019 at 8:13 PM Nick Bolten  wrote:
>
>> A recent post on the Mapillary blog (
>> https://blog.mapillary.com/update/2019/02/12/potential-for-openstreetmap-to-seize-the-curb.html)
>> reminded me of my long-running wish to have more curb lines mapped, so I
>> wanted to get a discussion started to see what people think of mapping
>> curbs as ways.
>>
>> The short version is this: if we put kerb=* on a line and call it its own
>> feature, what's the best tagging schema to use and what kind of additional
>> information is appropriate? Personally, I'd like to use (and recommend) the
>> existing kerb=* tags around blocks and potentially add parking information.
>>
>> Potential mapping and data use cases:
>>
>> - Public parking data: curbs are already marked with parking / stopping
>> information, and when motor vehicles stop at a curb they are meant to
>> follow the local regulations regarding access. Curbs seem like a natural
>> place to store this information: you can split the way whenever the parking
>> situation differs or where there are dedicated parking slots. It is
>> attractive to associate streets with parking information, but if one were
>> to split street ways whenever parking information changed, every city block
>> would become an incomprehensible, split-up mess.
>>
>> - Streets as areas: there are a few schemas out there about mapping
>> streets and related features as areas, primarily for rendering purposes.
>> Mapping the curb is fully compatible with, and part of, these proposals,
>> and could provide a means of building up to fully mapping contiguous areas.
>>
>> - Pedestrian crossings. I would be very excited to map out kerb=* ways
>> around every block I see, because it makes QA (and even safe,
>> semi-automated edits) for pedestrian accessibility so easy. All a validator
>> has to do is check that a highway=footway crosses a kerb=* way and lacks
>> its own kerb=* node. This is similar to the validators already used in JOSM
>> and iD that check for things like a footway or street intersecting a
>> building, reminding users to use covered=* or tunnel=*.
>>
>> - Pedestrian islands. These are often just an assembly of raised curbs
>> intended to protect pedestrians that are doing a multi-part crossing of a
>> street or streets.
>>
>> - Opportunity to merge with + simplify micromapped stairs: what are
>> stairs but a series of carefully-raised "curbs"? I've seen various
>> proposals regarding how one might map large, beautiful, public stairways.
>> This is a whole can of worms, but the information in describing a physical
>> curb is essentially the same as describing any 'stuff on the right is
>> higher than stuff on the left' interface.
>>
>> Thoughts?
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

2019-03-04 Thread Nick Bolten
Putting aside the preexistence of barrier=kerb + kerb=* on lines, do you
mean we should put kerb=* on a sidewalk line, a road line, or both? Keep in
mind that every time the kerb type changes, this would imply splitting the
way, so city street ways would be split another 2-8 times.

And what about parking information (e.g. hours, duration, type) that is
currently recommended as going on street ways? Should we split streets in
cities into 30 pieces?


On Sun, Mar 3, 2019, 3:06 PM Warin <61sundow...@gmail.com> wrote:

> On 04/03/19 06:12, Nick Bolten wrote:
> > A recent post on the Mapillary blog
> > (
> https://blog.mapillary.com/update/2019/02/12/potential-for-openstreetmap-to-seize-the-curb.html)
>
> > reminded me of my long-running wish to have more curb lines mapped, so
> > I wanted to get a discussion started to see what people think of
> > mapping curbs as ways.
> >
> > The short version is this: if we put kerb=* on a line and call it its
> > own feature, what's the best tagging schema to use and what kind of
> > additional information is appropriate? Personally, I'd like to use
> > (and recommend) the existing kerb=* tags around blocks and potentially
> > add parking information.
> >
> > Potential mapping and data use cases:
> >
> > - Public parking data: curbs are already marked with parking /
> > stopping information, and when motor vehicles stop at a curb they are
> > meant to follow the local regulations regarding access. Curbs seem
> > like a natural place to store this information: you can split the way
> > whenever the parking situation differs or where there are dedicated
> > parking slots. It is attractive to associate streets with parking
> > information, but if one were to split street ways whenever parking
> > information changed, every city block would become an
> > incomprehensible, split-up mess.
> >
> > - Streets as areas: there are a few schemas out there about mapping
> > streets and related features as areas, primarily for rendering
> > purposes. Mapping the curb is fully compatible with, and part of,
> > these proposals, and could provide a means of building up to fully
> > mapping contiguous areas.
> >
> > - Pedestrian crossings. I would be very excited to map out kerb=* ways
> > around every block I see, because it makes QA (and even safe,
> > semi-automated edits) for pedestrian accessibility so easy. All a
> > validator has to do is check that a highway=footway crosses a kerb=*
> > way and lacks its own kerb=* node. This is similar to the validators
> > already used in JOSM and iD that check for things like a footway or
> > street intersecting a building, reminding users to use covered=* or
> > tunnel=*.
> >
> > - Pedestrian islands. These are often just an assembly of raised curbs
> > intended to protect pedestrians that are doing a multi-part crossing
> > of a street or streets.
> >
> > - Opportunity to merge with + simplify micromapped stairs: what are
> > stairs but a series of carefully-raised "curbs"? I've seen various
> > proposals regarding how one might map large, beautiful, public
> > stairways. This is a whole can of worms, but the information in
> > describing a physical curb is essentially the same as describing any
> > 'stuff on the right is higher than stuff on the left' interface.
> >
> > Thoughts?
>
> Err ... no.
> Curbs and guttering are road edges. Detail them as part of the road/foot
> path.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

2019-03-04 Thread yo paseopor
It is the same story again and again.

-First was the node and ways. And some classification . It was not enough
-Second arrived relations. but when you want to specify more..it is not
enough
-Then it was other tags like classification, lanes, sidewalks...  it is not
enough if you want to make all the details.
-Then arrived the area mapping to make it more realistic. But only for some
items as sidewalks.
Congrats , now we need the detail of a kerb drawed as an area.

I think best way at first is using the same tagging we have for kerb
https://wiki.openstreetmap.org/wiki/Key:kerb
https://taginfo.openstreetmap.org/search?q=kerb#keys

Then...you know you will need more tags...cuz it is not enough ;)
PD: don't map for the render (instead it would be OSM official's one). All
real info is welcomed

Salut i mapes
yopaseopor

On Sun, Mar 3, 2019 at 8:13 PM Nick Bolten  wrote:

> A recent post on the Mapillary blog (
> https://blog.mapillary.com/update/2019/02/12/potential-for-openstreetmap-to-seize-the-curb.html)
> reminded me of my long-running wish to have more curb lines mapped, so I
> wanted to get a discussion started to see what people think of mapping
> curbs as ways.
>
> The short version is this: if we put kerb=* on a line and call it its own
> feature, what's the best tagging schema to use and what kind of additional
> information is appropriate? Personally, I'd like to use (and recommend) the
> existing kerb=* tags around blocks and potentially add parking information.
>
> Potential mapping and data use cases:
>
> - Public parking data: curbs are already marked with parking / stopping
> information, and when motor vehicles stop at a curb they are meant to
> follow the local regulations regarding access. Curbs seem like a natural
> place to store this information: you can split the way whenever the parking
> situation differs or where there are dedicated parking slots. It is
> attractive to associate streets with parking information, but if one were
> to split street ways whenever parking information changed, every city block
> would become an incomprehensible, split-up mess.
>
> - Streets as areas: there are a few schemas out there about mapping
> streets and related features as areas, primarily for rendering purposes.
> Mapping the curb is fully compatible with, and part of, these proposals,
> and could provide a means of building up to fully mapping contiguous areas.
>
> - Pedestrian crossings. I would be very excited to map out kerb=* ways
> around every block I see, because it makes QA (and even safe,
> semi-automated edits) for pedestrian accessibility so easy. All a validator
> has to do is check that a highway=footway crosses a kerb=* way and lacks
> its own kerb=* node. This is similar to the validators already used in JOSM
> and iD that check for things like a footway or street intersecting a
> building, reminding users to use covered=* or tunnel=*.
>
> - Pedestrian islands. These are often just an assembly of raised curbs
> intended to protect pedestrians that are doing a multi-part crossing of a
> street or streets.
>
> - Opportunity to merge with + simplify micromapped stairs: what are stairs
> but a series of carefully-raised "curbs"? I've seen various proposals
> regarding how one might map large, beautiful, public stairways. This is a
> whole can of worms, but the information in describing a physical curb is
> essentially the same as describing any 'stuff on the right is higher than
> stuff on the left' interface.
>
> Thoughts?
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Clarification unclassified vs residential

2019-03-04 Thread djakk djakk
Hello Mateusz,

You can not render correctly with a bad tagging, and that is the case here
: in France, a trunk road have 2 lanes and oneway=yes by default, not in
UK.

I understand your criticism about the values I’ve used, it is not
definitive :).

Except maybe the values for road_level : they should be like the values of
admin_level.


Julien “djakk”



Le dim. 3 mars 2019 à 20:21, Mateusz Konieczny  a
écrit :

> "I would have expected the first road be rendered not like the 3 last
> roads,
> those last 3 roads should have been rendered the same as they look the
> same"
>
> Is it tagging or rendering discussion?
>
> Because as far as as rendering is concerned you can already do that, just
> use surface/lanes/oneway tags.
>
> In general highway=* tag is not about how road looks like, it is rather
> about its
> importance in road system (with sole exception of highway=motorway).
>
> It is hard to be sure without real proposal but I am not fan of tags like
> looks_like=FR_urban_motorway or road_class=UK_motorway
>
> And I am against tags like importance_local=5 or road_level=1.
> Numeric values in tracktype=* were a mistake, it is really hard to
> remember
> what is the difference between tracktype=grade3 and tracktype=grade4.
>
> Mar 3, 2019, 7:02 PM by djakk.dj...@gmail.com:
>
> Hello !
>
> I’ve updated
> https://wiki.openstreetmap.org/wiki/User:Djakk/new_tagging_scheme_for_roads
>
> To answer the original question of this thread, I wish you can use
> importance_local=5 or 6 with abutters=rural or residential ;)
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "satellit"

2019-03-04 Thread Sergio Manzi
On 2019-03-04 11:54, Martin Koppenhoefer wrote:
> Do not counter this with "not sufficiently relevant for mapping", as you'll 
> see people will likely tag it ;-)


Personally I counter this for lack of observability/verifiability.

From https://wiki.openstreetmap.org/wiki/Verifiability

"At the core, "verifiability" is that everything you do can be demonstrated 
to be true or false - the latter hopefully implying that there has been a 
change on the ground that needs mapping. We apply this not only to the mapping 
data itself, but also to the way in which we record it - the tags and values we 
use to describe the attributes of objects on the map. From a given scenario, a 
tag/value combination is verifiable *if and only if* independent users when 
observing the same feature would make the same observation every time. For a 
user's tagging to be verifiable, it is desirable to have objective criteria for 
tagging. This principle applies to any observable characteristic which is a 
matter of fact, be it numerical or descriptive - a concrete road surface, a red 
brick building, etc. "

Isn't the above an OSM tenet any more?

Sergio


P.S.: yeah, I know it is a "lost cause", but anyway...



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "satellit"

2019-03-04 Thread Martin Koppenhoefer
I would expect the "uplink" information to be relevant, as most satellite
antennas are used for receiving only (those private tv reception antennas).
Do not counter this with "not sufficiently relevant for mapping", as you'll
see people will likely tag it ;-)

Subtagging (or a property) seems better for the "uplink" information,
because it doesn't require people to know the details in order to map
something, I agree.

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] "satellit"

2019-03-04 Thread Jean-Marc Liotier
https://taginfo.openstreetmap.org/keys/antenna%3Atype#values mentions
"parabolic_satellit" "parabolic_satellit_uplink" and
"parabolic_satellite_uplink". I have two remarks about that...

First, evidently, "satellit" is wrong and should be "satellite"... Or have
I missed something ? Unless someone explains that "satellit" is a distinct
legit concept, I'll replace it globally with "satellite".

Second, do we want to specify "_uplink" where appropriate ? Most parabola
large enough to tag in Openstreetmap are going to feature an uplink. But
most important, the physical features of downlink and uplink/downlink
antennas are identical - the same antenna might even have more than one
feeder to switch its purpose. So, should we have only
"parabolic_satellite" or both "parabolic_satellite" and
"parabolic_satellite_uplink" ? Or should we leave the antenna's purpose to
a subtag (something like
antenna:purpose=downlink;uplink;uplink/downlink;tracking;etc.) ? I admit I
like the subtag option because it shifts the problem to somewhere it won't
complicate the mapping of physical features...

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] tagging laboratories

2019-03-04 Thread Martin Koppenhoefer
Am Mo., 4. März 2019 um 09:37 Uhr schrieb Warin <61sundow...@gmail.com>:

>
>
> These can be commercialfirms, part of the government, or part of a
> university etc.
>
> They usually specialise in one field so will need sub tags.




I would question whether we put all kind of "laboratory" into the same
category and distinguish them by subtags. There are too many different kind
of things that could be subsummized as "laboratory". Think about eletronic
laboratories, chemistry research labs, biochemical labs, labs for human
healtcare analytics, etc.
First distinction could be "research lab" vs. "analytical lab" vs. maybe
more types, and these should IMHO become main tags, not subtags.

There is also some potential confusion with the word "laboratory" being
used as a hyped name for workspace where you would not expect it, e.g.
software laboratory, architectural design laboratory, art laboratory, etc.
So we would need some definition, what the criterion for "laboratory" is
(or is it the name?).

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] tagging laboratories

2019-03-04 Thread Mateusz Konieczny



Mar 4, 2019, 9:35 AM by 61sundow...@gmail.com:

> Hi,
>
> From
>
> https://help.openstreetmap.org/questions/62806/how-to-tag-a-research-laboratory
>  
> 
>
> and
>
> https://www.openstreetmap.org/user/thevikas/diary/47849 
> 
>
> There appearsto be no information on how to tag a laboratory.
>
> https://en.wikipedia.org/wiki/Laboratory 
> 
>
> These can be commercialfirms, part of the government, or part of a university 
> etc.
>
>From https://wiki.openstreetmap.org/wiki/Tag:healthcare%3Dlaboratory 
>
and taginfo https://taginfo.openstreetmap.org//search?q=laboratory 


It seems that there is established method for healthcare laboratories and 
others are so
far without a good tag

There is a laboratory key https://taginfo.openstreetmap.org/keys/laboratory 
 used a bit

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] tagging laboratories

2019-03-04 Thread Warin

Hi,

From

https://help.openstreetmap.org/questions/62806/how-to-tag-a-research-laboratory

and

https://www.openstreetmap.org/user/thevikas/diary/47849

There appearsto be no information on how to tag a laboratory.

https://en.wikipedia.org/wiki/Laboratory

These can be commercialfirms, part of the government, or part of a 
university etc.


They usually specialise in one field so will need sub tags.

Discussion?


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging