Hi Fernando,
To start here, have a good 2020.
I have been active laying bricks and stones (vert & hor), some people will
notice the patterns, but not the sizes.
How about the thickness of pavement in pedestrian area's ? Are you aware of the
fact that they will be good to walk (4,5 cm) but for a ride you’ll need 6 - 8
cm or more to let an HGV pass without damaging the pavement ?
My other argument is why using Wikipedia as a source, its IMHO the last place I
would look for reliable info, good for using in OSM, another mapper should be
able to control my doings. Since every one is able to ad to pedia its not a
very well or reliable source to quote that is not the case with that medium it
can or will change. And even "mistakes" can be un attended there for ever, so
don’t quote another Wiki's then our own is the most reasonable is not it ?
The technic of laying bricks like that is called Vleiwerk, the bricks are
placed on a very well prepared strech of sand, even a robot could do 100 or
more at once. But they still have to be tightened together by using a shaker,
the old not even likely shaped by hand, just putting a lump of clay in a
squarre made box. They could be 3-4 mm difference in thickness and form not a
match for an robot to cope with so one for one for all, to form a pavement.
Greetz
Hendrikklaas
Ps did you ever walked a flagstone surface during or after a rainy day ? It
will be a slippery surface with dangers for oldies and cyclists. I would expect
a router to tell me if a cycle route is planned over cobblestones as it is not
very even.
________________________________
Van: tagging-requ...@openstreetmap.org <tagging-requ...@openstreetmap.org>
Verzonden: donderdag 9 januari 2020 02:14
Aan: tagging@openstreetmap.org <tagging@openstreetmap.org>
Onderwerp: Tagging Digest, Vol 124, Issue 40
Send Tagging mailing list submissions to
tagging@openstreetmap.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.openstreetmap.org/listinfo/tagging
or, via email, send a message with subject or body 'help' to
tagging-requ...@openstreetmap.org
You can reach the person managing the list at
tagging-ow...@openstreetmap.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Tagging digest..."
Today's Topics:
1. Re: surface=block_paved, or surface=paved + paving=block
(Paul Allen)
2. Re: amenity=tourist_bus_parking (Volker Schmidt)
3. Re: Feature proposal - RFC - Overhead lines management
(consecutive to line_attachment) (François Lacombe)
4. Re: surface=block_paved, or surface=paved + paving=block
(Fernando Trebien)
5. Re: How to tag oneway restriction applying to pedestrians?
(Jarek Piórkowski)
----------------------------------------------------------------------
Message: 1
Date: Wed, 8 Jan 2020 23:22:38 +0000
From: Paul Allen <pla16...@gmail.com>
To: "Tag discussion, strategy and related tools"
<tagging@openstreetmap.org>
Subject: Re: [Tagging] surface=block_paved, or surface=paved +
paving=block
Message-ID:
<capy1dokyxvxdqhufuqfq+yhvhynbgehot2kkaxdajaf4t0s...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Wed, 8 Jan 2020 at 23:06, marc marc <marc_marc_...@hotmail.com> wrote:
> why it isn't a paving_stones ? the max height ?
>
Shape and size.
https://en.wikipedia.org/wiki/Brick#Optimal_dimensions,_characteristics,_and_strength
I ask myself how and how many mappers 'll see a diff.
>
Any who have ever laid bricks, or handled bricks, or seen bricks. Maybe.
Oh, and those who happened to watch a YouTube video about the history of
bricks, :)
--
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openstreetmap.org/pipermail/tagging/attachments/20200108/5e3ade85/attachment-0001.htm>
------------------------------
Message: 2
Date: Thu, 9 Jan 2020 00:37:00 +0100
From: Volker Schmidt <vosc...@gmail.com>
To: "Tag discussion, strategy and related tools"
<tagging@openstreetmap.org>
Subject: Re: [Tagging] amenity=tourist_bus_parking
Message-ID:
<CALQ-OR4VZtQigNtpx=5mtgosqbencsvn8_njpomqtngpktw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
It is not unusual to have one parking area with one name with dedicated
areas for different vehicle categories. I cannot use amenity=parking for
both the entire parking area and the vehicle-type-specific "sub"-areas, at
least JOSM does complain when you do that. We could ignore that and use
nested amenity=parking tags.
.
On Wed, 8 Jan 2020, 15:52 John Willis via Tagging, <
tagging@openstreetmap.org> wrote:
> If I have a sign that says all cars go here, and all HGV goes over there,
> and one is painted for 1000 car spots and one has 50 giant bus spots, those
> are designated lots.
>
> I have used parking_space when I have found A lone disabled space - but a
> group of 50 spots for busses is a bus lot.
>
> At least being able to say “this is the lot for busses” as an attribute of
> amenity=parking should be doable (with a subtag).
>
> Javbw
>
> On Jan 8, 2020, at 7:18 PM, Volker Schmidt <vosc...@gmail.com> wrote:
>
> make use of the fact that amenity=parking_space
> <https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space> can be
> used for this.
> Make separate parking space areas for different vehicle types.
>
> _______________________________________________
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openstreetmap.org/pipermail/tagging/attachments/20200109/338c931d/attachment-0001.htm>
------------------------------
Message: 3
Date: Thu, 9 Jan 2020 01:08:20 +0100
From: François Lacombe <fl.infosrese...@gmail.com>
To: "Tag discussion, strategy and related tools"
<tagging@openstreetmap.org>
Subject: Re: [Tagging] Feature proposal - RFC - Overhead lines
management (consecutive to line_attachment)
Message-ID:
<cag0yglcthznzcas5sooy7ej3hsnirxh0wwyrhhbqwfycij2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
This proposal is still in RFC and may be voted in a couple of weeks as
evaluation shown no issue so far, at least on transmission power lines.
line_management tag is used carefully for testing.
Read more : https://www.openstreetmap.org/user/InfosReseaux/diary/391058
Nevertheless it's an opportunity to review the branch:type tag replacement
with line_management=*
i'm still looking for an appropriate illustration for two values examples:
* line_management=cross (two or more lines with different directions
sharing the same support without connecting)
* line_management=loop (two or more lines coming from the same direction
are connected as to mock some of them)
Feel free to propose and complete if you find corresponding situations on
ground
Thanks in advance
François
Le sam. 26 oct. 2019 à 20:59, François Lacombe <fl.infosrese...@gmail.com>
a écrit :
> Hi all,
>
> After the review of line_attachment key this summer and Karlsruhe
> hackweekend at Geofabrik headquarters last week, let me introduce the
> second stage of tower:type key cleaning project for power lines. Great time
> has been spent on discussing and finding relevant situations.
> https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management
>
> It's now about the arrangement of power lines around their supports: how
> the lines branch, split, transpose or terminate.
> As current tagging (without line_management) still collides with any tower
> building function, the line_management key may be a solution to strip
> unrelated values from tower:type.
>
> I've published a diary entry to give more explanations
> https://www.openstreetmap.org/user/InfosReseaux/diary/391058
>
> I'd draw your attention to the conclusion :
> "Mapping utility supports like power towers or telecom poles is a
> worldwide challenge. For instance in France, professionals including
> operators and contractors rolling out overhead telecom cables are currently
> looking for approx. 16 millions missing shared power poles that weren’t
> mapped in operational GIS. There’s no doubt updating OSM can help."
> There's no short term risk of importing massive data, at least.
>
> This proposal is a first try and may cause worries about some local
> concerns. RFC is here to solve this prior to vote anything.
> We have to focus on simple situations to begin with to adopt the right
> semantic. More complex cases will be added step by step.
> Feel free to open a topic in Talk page.
>
> All the best
>
> François
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openstreetmap.org/pipermail/tagging/attachments/20200109/d16640ce/attachment-0001.htm>
------------------------------
Message: 4
Date: Wed, 8 Jan 2020 22:14:00 -0200
From: Fernando Trebien <fernando.treb...@gmail.com>
To: "Tag discussion, strategy and related tools"
<tagging@openstreetmap.org>
Subject: Re: [Tagging] surface=block_paved, or surface=paved +
paving=block
Message-ID:
<CABcWbR69dVLJL=x8fcprxq6mowyajqokb1bnfx-a_cr_rru...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
>From the key:surface article:
- surface=paved: "This value gives only a rough description; use a
more precise value if possible."
- surface=paving_stones: "A relatively smooth surface paved with
artificial blocks (block pavers, bricks) or natural stones
(flagstones), with a flat top. The gaps between individual paving
stones are very narrow, either because the stones have a perfectly
regular shape (rectangular, or any surface-filling shape) or because
they have been carefully selected, fitted and placed in order to form
an even, closed surface."
The picture [1] fits the description for surface=paving_stones, and
I've been told that the description fits current mapping practices.
[2] So the question is whether the mapping terminology fits the common
language and whether this would be a good reason to change the tagging
scheme. Language is a problem for other values as well, such as
surface=cobblestone. Since surface=* is, in principle, an open set, it
may be interesting asking if it is worth distinguishing the three
subtypes (block pavers, bricks, and flagstones) for data consumers
(routing, rendering, etc.). I don't see when the distinction would be
really important, and in fact many of the values in current use are
not yet supported by the oldest data consumers.
There seems to be almost no usage of paving=*, [3] I'm not sure this
would be ideal.
[1] https://commons.wikimedia.org/wiki/File:Paving_being_laid_arp.jpg
[2] https://forum.openstreetmap.org/viewtopic.php?id=61042|
[3] https://taginfo.openstreetmap.org/keys/paving#value
On Wed, Jan 8, 2020 at 7:37 PM Mateusz Konieczny
<matkoni...@tutanota.com> wrote:
>
> Is following picture
> https://commons.wikimedia.org/wiki/File:Paving_being_laid_arp.jpg
> depicting construction of surface=paving_stones?
>
> Or is it incorrect to tag in this way and
> surface=block_paved, or surface=paved + paving=block
> should be considered as preferable?
>
> Posted to look for more feedback in
> https://wiki.openstreetmap.org/wiki/Talk:Tag:surface%3Dpaving_stones
> discussion.
>
> _______________________________________________
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
--
Fernando Trebien
------------------------------
Message: 5
Date: Wed, 8 Jan 2020 20:14:11 -0500
From: Jarek Piórkowski <ja...@piorkowski.ca>
To: "Tag discussion, strategy and related tools"
<tagging@openstreetmap.org>
Subject: Re: [Tagging] How to tag oneway restriction applying to
pedestrians?
Message-ID:
<cacv3h2ntf7zcq_mpvvtm66hqjrjfxp_1zlbt0o3w4nxen5l...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Wed, 8 Jan 2020 at 16:33, Mateusz Konieczny <matkoni...@tutanota.com> wrote:
> Although unusual, oneway on pedestrian highways (path, footway, track) is
> possible in some places.
>
> Cases of oneway pedestrian traffic includes some hiking trails, border
> crossing,
> exit-only passages and more.
>
> How to tag this?
Would just like to note that oneway=yes is established on
highway=steps (usually with conveying=yes, i.e., an escalator) to the
point where a major data consumer openstreetmap-carto supports it,
e.g. https://www.openstreetmap.org/way/367618960
Arguably escalators are a special case since unlike most footways
there is a mechanical component to them. However I would still be
interested in seeing any tagging for footways maintain at least some
consistency with it.
If this is hugely problematic for data consumers I would not be
opposed to tagging like highway=footway + foot:backward=no, with
oneway=yes allowed as optional for human readability.
--Jarek
------------------------------
Subject: Digest Footer
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
------------------------------
End of Tagging Digest, Vol 124, Issue 40
****************************************
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
