[Tagging] Tagging Digest, Vol 124, Issue 40 brick laying technics.

St Niklaas st.niklaas at live.nl
Thu Jan 9 14:56:06 UTC 2020


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-request at openstreetmap.org <tagging-request at openstreetmap.org>
Verzonden: donderdag 9 januari 2020 02:14
Aan: tagging at openstreetmap.org <tagging at openstreetmap.org>
Onderwerp: Tagging Digest, Vol 124, Issue 40

Send Tagging mailing list submissions to
        tagging at 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-request at openstreetmap.org

You can reach the person managing the list at
        tagging-owner at 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 <pla16021 at gmail.com>
To: "Tag discussion, strategy and related tools"
        <tagging at openstreetmap.org>
Subject: Re: [Tagging] surface=block_paved, or surface=paved +
        paving=block
Message-ID:
        <CAPy1dOKYxvXDQHufuQfQ+YhvhyNBGehoT2kkAxDAJaF4T0SCKA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Wed, 8 Jan 2020 at 23:06, marc marc <marc_marc_irc at 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 <voschix at gmail.com>
To: "Tag discussion, strategy and related tools"
        <tagging at openstreetmap.org>
Subject: Re: [Tagging] amenity=tourist_bus_parking
Message-ID:
        <CALQ-OR4VZtQigNtpx=5mTGosQBEncsVN8_NjPomqTNGpktWtvQ at 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 at 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 <voschix at 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 at 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.infosreseaux at gmail.com>
To: "Tag discussion, strategy and related tools"
        <tagging at openstreetmap.org>
Subject: Re: [Tagging] Feature proposal - RFC - Overhead lines
        management (consecutive to line_attachment)
Message-ID:
        <CAG0ygLcThZNzCas5SOOy7Ej3hsNiRxh0wwyRhHBqWfYCiJ2bjA at 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.infosreseaux at 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.trebien at gmail.com>
To: "Tag discussion, strategy and related tools"
        <tagging at openstreetmap.org>
Subject: Re: [Tagging] surface=block_paved, or surface=paved +
        paving=block
Message-ID:
        <CABcWbR69dVLJL=x8FCPRXQ6mOWYAjqOkb1bNFx-a_cR_rRu0+Q at 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
<matkoniecz at 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 at 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 <jarek at piorkowski.ca>
To: "Tag discussion, strategy and related tools"
        <tagging at openstreetmap.org>
Subject: Re: [Tagging] How to tag oneway restriction applying to
        pedestrians?
Message-ID:
        <CACV3h2nTF7ZCQ_MpVvtm66HQjrJfXp_1zLbt0O3W4NxEN5L58g at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

On Wed, 8 Jan 2020 at 16:33, Mateusz Konieczny <matkoniecz at 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 at openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


------------------------------

End of Tagging Digest, Vol 124, Issue 40
****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200109/139025fb/attachment-0001.htm>


More information about the Tagging mailing list