sent from a phone
> On 23. Aug 2020, at 23:20, pangoSE wrote:
>
> This collides with one feature one element does it not?
it does not. An address is not (necessarily) a feature, it can also be a
property
> Can you give an example of what you mean by stable?
if you move the POI or the b
sent from a phone
> On 23. Aug 2020, at 21:52, Michael Schmidt via Tagging
> wrote:
>
> But this does not reflect current practice.
> I have randomly checked bus relations in Berlin, Hamburg, Cologne and Munich
> and found, that the practice comes very different.
> Some without abbreviation,
sent from a phone
> On 23. Aug 2020, at 23:39, Joseph Eisenberg
> wrote:
>
> Hostile architecture is also employed to deter skateboarding, littering,
> loitering, and public urination."
>
> There is an example of a 1800s church with a sloped wall, designed to deflect
> urine
great you me
sent from a phone
> On 23. Aug 2020, at 23:20, Peter Elderson wrote:
>
> The British really call bench construction "architecture"?
I may be misguided but I believe the term is “urban decor” for these things,
including street lights, bins, planters etc. and yes, it is often designed by
arc
sent from a phone
> On 23. Aug 2020, at 22:24, Joseph Eisenberg
> wrote:
>
> We want to make it clear that lying down or sitting down is not allowed or
> physical obstructed, right?
I think the focus is on physically obstructed, although this is also not very
easy to decide in every case,
sent from a phone
> On 24. Aug 2020, at 00:06, Mateusz Konieczny via Tagging
> wrote:
>
> Tagging multiple ref on one road, if road carries multiple routes is
> routinely done already.
>
> roundabout is not changing anything here
+1, ref on highways refers to routes, it’s legacy. If there
sent from a phone
> On 23. Aug 2020, at 18:53, Thibault Molleman
> wrote:
>
> Should that entrance node also have the
> addr:housenumber=15
> tag or is it assumed based on it being placed on the building's way?
The addr:housenumber ideally should be added to the object to which it applies
sent from a phone
> On 23. Aug 2020, at 18:40, Oliver Simmons wrote:
>
> I agree with the `hostile_architecture=` tag as this could be expanded on in
> the future
I can see the point, but it is probably not verifiable in many instances (it
could be seen as hostile but it could have other r
sent from a phone
> On 23. Aug 2020, at 15:45, Paul Allen wrote:
>
> I have a vague recollection of bridge:name being introduced because some
> people were unhappy with using name for the name of the bridge. They
> argued that name should be the name of the road and bridge:name should
> be us
sent from a phone
> On 23. Aug 2020, at 14:31, Volker Schmidt wrote:
>
> name=* for a tunnel's name that is mapped with tunnel=yes seems to be common
> practice (at least 760 motorway tunnels in Italy are tagged this way).
> On the other hand we do have many tunnels, where the road in the tu
sent from a phone
> On 23. Aug 2020, at 10:17, Jo wrote:
>
> The house number is not 12 and it is not 14, it actually is 12-14, because 2
> buildings were torn down and a single building was built instead of it. This
> also happens when people or companies acquire 2 adjacent buildings, they
sent from a phone
> On 22. Aug 2020, at 23:22, Arne Johannessen wrote:
>
> That's not what I'm saying at all. In fact, I'm only applying *exactly*
> what's currently documented on the wiki's name=* page, which considers
> pragmatics instead of semantics.
>
> In other words, instead of focus
sent from a phone
> On 22. Aug 2020, at 13:06, Warin <61sundow...@gmail.com> wrote:
>
> Would that be acceptable?
words are better IMHO, easier to remember and faster to type...
Cheers Martin
___
Tagging mailing list
Tagging@openstreetmap.org
ht
sent from a phone
> On 22. Aug 2020, at 11:05, Michael Schmidt via Tagging
> wrote:
>
> But I prefer the short version and am tagging it..
the general rule is “no abbreviations” and shortenings will make collisions
much more probable...
Cheers Martin
_
sent from a phone
> On 22. Aug 2020, at 13:18, Alan Mackie wrote:
>
> There seems to be some overlap with the values of the bridge key.
> https://wiki.openstreetmap.org/wiki/Key:bridge
this is because the bridge:structure key was introduced later on, before we
lumped everything into “bridg
sent from a phone
> On 22. Aug 2020, at 12:11, Jake Edmonds via Tagging
> wrote:
>
> Doesn’t bridge:structure refer to the design of the supports?
I would say bridge:structure refers to the structural system of the bridge
(e.g. arch, beam, pylon with ropes, etc.) so I agree that it is not
sent from a phone
> On 22. Aug 2020, at 12:18, Florian Lohoff wrote:
>
> Adding all refs of all streets PLUS that of the roundabout would
> make it even worse as you couldnt distinguish which of the refs
> references the Roundabout and which of the refs is that of the streets.
typically the
sent from a phone
> On 22. Aug 2020, at 12:11, Mateusz Konieczny via Tagging
> wrote:
>
> I would expect roundabout to be split in parts where
> ref is applying and parts where it is not applying, in other words
> without any special handling and tag it as usual.
+1
Cheers Martin
sent from a phone
> On 22. Aug 2020, at 09:25, Thibault Molleman
> wrote:
>
> So what's the consensus on an apartment building (way) that has mailboxes for
> each person who has an apartment there.
> I've just been tagging those as:
> addr:housenumber = A1;A2;A3;A4;A5;A6;A7;A8;A9;A10;A11
a
sent from a phone
> On 21. Aug 2020, at 22:25, Andy Mabbett wrote:
>
> "public building" and "trunk highway" are also common terms.
>
> Do we tag
>
>building=public_building
>
> or
>
>highway=trunk_hghway
these are different because it would be a literal repetition. What we do is
sent from a phone
> On 21. Aug 2020, at 20:53, Andy Mabbett wrote:
>
> What type of footway is not a walkway?
>
> What type of walkway is not a footway?
>
> The two terms are synonyms; using them twice is therefore a tautology.
the term as I understand it is „canopy walkway“ not „walkway“.
sent from a phone
> On 21. Aug 2020, at 15:18, Andy Mabbett wrote:
>
> That's a tautology (consider: footway=walkway) and can be reduced to:
>
> footway=canopy
it is not a tautology, it’s a subtype, footway=canopy sounds horrible (maybe
that’s just me?)
>
> or better:
>
> footway=t
sent from a phone
> On 21. Aug 2020, at 14:33, Michael Schmidt via Tagging
> wrote:
>
> OK, in this case I must tag the state network twice - for LSB and SKV...
>
> What do you think about that?
I would prefer the long version (less duplicates of different entities) and
just a single tag
sent from a phone
> On 21. Aug 2020, at 03:34, 80hnhtv4agou--- via Tagging
> wrote:
>
> in the united states it is Curb.
in Germany it is Bordstein
Cheers Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/
sent from a phone
> On 21. Aug 2020, at 01:05, Clifford Snow wrote:
>
> Martin - does that suggest that over 12,000 existing raised kerbs will need
> to be resurveyed?
that’s how I read it, and there are actually 28.4K raised kerbs affected
(because you have to look at the ways as well).
sent from a phone
> On 20. Aug 2020, at 23:18, Volker Schmidt wrote:
>
> What's wrong with "bridge" ?
it’s ok, but not sufficient when you want to search them.
Maybe something like leisure=canopy_walkway or tourism=canopy_walkway (in
addition)?
Or maybe footway=canopy_walkway? highway= Foot
Worth mentioning that the proposal intends to redefine the tag kerb=raised ,
true?
Cheers Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
sent from a phone
> On 20. Aug 2020, at 15:29, Mateusz Konieczny via Tagging
> wrote:
>
> And it may be useful to have tag to mark "yes this is actually a single
> housenumber despite
> that includes hyphen or something else that suggests range"
referring to addresses or to housenumbers,
sent from a phone
> On 20. Aug 2020, at 14:29, Tobias Zwick wrote:
>
> I am not sure what is the message of your statement. Is this just a
> general opinion regarding speed limits or is this somehow referring to
> the explanation I linked in the thread starter?
I have commented on your point
I feel that the actual tags for implicit limits are less important than the
accuracy of the information. From surveys, in different countries (but clearly
random samples and no systematic research), it’s not super rare to find
implicit limits tagged where there are (lower) signed speed limits on
sent from a phone
>> On 19. Aug 2020, at 15:33, woll...@posteo.de wrote:
> I could imagine rare cases of a privately run cemetery not linked to any
> religion or belief/life stance and where there is such a building. But
> typically, they would be public.
let me rephrase my question: how imp
sent from a phone
> On 19. Aug 2020, at 14:00, Philip Barnes wrote:
>
> Looking around my local area these have simply been mapped as
> amenity=crematorium.
i.e. they have not been mapped yet :)
a crematorium implies a place to burn dead people or animals, but has no
implications on the pr
sent from a phone
> On 19. Aug 2020, at 10:23, woll...@posteo.de wrote:
>
> Indeed, this is not about a business, but a public facility
must the facility be “public” or could it be a private facility as well?
Cheers Martin
___
Tagging mailing list
sent from a phone
> On 19. Aug 2020, at 01:38, Joseph Eisenberg
> wrote:
>
> similar meaning for funeral homes / funeral halls / funeral directors:
> shop=funeral_directors.
> The use of the key "shop=" is odd, but it's been used over 20,000 times so it
> seems to be well established:
th
sent from a phone
> On 18. Aug 2020, at 05:34, Paul White wrote:
>
> I wanted to raise a concern about tagging house numbers on a building using a
> hyphen to denote the address range (e.g 33-55 Main Street).
I am not sure for buildings, but for addresses I use this all the time, because
t
sent from a phone
> On 17. Aug 2020, at 05:51, Yves wrote:
>
> station:type is still available then.
sure, I wrote:
“ (I am not an expert for aerialway station types, but sooner or later someone
will come along who is, and even if they decide to use “station” for these
potential subtypes,
sent from a phone
> On 17. Aug 2020, at 00:25, Colin Smale wrote:
>
> Other attributes like the presence of the drive motors, ticket sales etc are
> not determinants of the "valley" vs "mountain" labels.
I have followed this discussion, my comment was that there may well be other
types of
sent from a phone
>> On 16. Aug 2020, at 15:26, dktue wrote:
> Ok, then I'm going to edit the wiki [1] now.
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:aerialway=station
>
sorry for this late comment, but maybe it would be better to use
station:position=top/mid (or middle) / bottom
r
sent from a phone
> On 16. Aug 2020, at 13:55, Colin Smale wrote:
>
> You can't have a mid terminal, by definition.
right, this is also something that always bothered me with our way of tagging
ferry stations.
Cheers Martin
___
Tagging mailin
sent from a phone
> On 16. Aug 2020, at 01:06, Graeme Fitzpatrick wrote:
>
> I'd leave it up to his listed website, &, if necessary, his receptionist :-)
or just the name, people could google for the website ;-)
Seriously, I am in favor of adding such detail in a semantic way. If we all do
sent from a phone
> On 16. Aug 2020, at 01:06, Graeme Fitzpatrick wrote:
>
> Having said that, though, I'd also agree with you that lice is a "health"
> issue, so healthcare= seems a better option.
+1, while not actually dangerous in most cases (transmission of other diseases
is possible i
sent from a phone
> On 15. Aug 2020, at 17:31, Peter Elderson wrote:
>
> a continuous line of evenly spaced trees at both sides, sometimes also in the
> middle, sometimes double or triple rows at each side, often with a separately
> lined cycleway and tree_lined ditches.
thank you for brin
sent from a phone
> On 15. Aug 2020, at 17:33, Arne Johannessen wrote:
>
> Therefore, the tunnel's name is the primary name for that particular way, and
> thus belongs into the name=* tag.
>
> The full name tagging for a road tunnel should usually look like this:
>
> name=The Tunnel
> highw
sent from a phone
> On 15. Aug 2020, at 19:12, Paul Allen wrote:
>
> If we decide that
> we want to tag such things in the first place.
as there was significant discussion how to tag them, it doesn’t seem that not
mapping them is an option we still have to discuss
Cheers Martin
_
sent from a phone
>> On 15. Aug 2020, at 13:47, Mateusz Konieczny via Tagging
>> wrote:
> I oppose such potential removal
here is an example:
https://wiki.openstreetmap.org/wiki/Highways
this is maybe not bad as a general overview, but then it duplicates significant
part of the information
sent from a phone
> On 15. Aug 2020, at 13:47, Mateusz Konieczny via Tagging
> wrote:
>
> I oppose such potential removal
referring to which page?
Cheers Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/li
sent from a phone
> On 15. Aug 2020, at 07:32, Volker Schmidt wrote:
>
> would suggest to create a single wiki page for tree-lined road mapping, so
> that we have one place where we describe the three different approaches for
> mapping them.
we have one place (the wiki) and the possible wa
sent from a phone
> On 15. Aug 2020, at 07:32, Volker Schmidt wrote:
>
> I do see these issues with adding sidewalks and cycle paths, where we have a
> similar choice between mapping as separate objects or as road property.
it is often perceived as an either or choice, but there is no reaso
sent from a phone
> On 15. Aug 2020, at 01:21, Arne Johannessen wrote:
>
> That's precisely why man_made=tunnel is so rare.
IMHO a tunnel is more than the way through it, the ventilation shafts, escape
ways, also arguably all the tubes, could be considered „the tunnel“. The reason
it is not
sent from a phone
> On 15. Aug 2020, at 00:36, Arne Johannessen wrote:
>
> However, name=* should always contain the primary name of a feature. For a
> road tunnel, the primary name is typically the tunnel's name, as the tunnel
> is usually a more prominent feature than the road is.
IMHO a
sent from a phone
> On 14. Aug 2020, at 23:56, Paul Allen wrote:
>
> I'd almost think you were talking of the landscaping feature of private
> gardens known as an avenue
yes, think of these, but also on public roads (although they’re an ornamental
feature and not just functional), basically
sent from a phone
> On 14. Aug 2020, at 22:50, Paul Allen wrote:
>
> Trees at
> the side of the road are an incidental. Fields at the side of the road are an
> incidental. Quaint houses at the side of the road are an incidental.
no, the trees we are looking at are not incidental, they are
sent from a phone
> On 14. Aug 2020, at 22:24, Martin Koppenhoefer wrote:
>
>> Both tags allow tents, and both allow camper vans and caravans.
>
>
> interesting, I would have expected a caravan site to not permit tents by
> default.
actually the caravan site puts
sent from a phone
> On 14. Aug 2020, at 22:09, Mateusz Konieczny via Tagging
> wrote:
>
> - The tag tents=yes/no (only listed in the camp_site Wiki) would be a good
> way to find a place to camp with a tent, but almost none of the caravan_site
> have this tag. All camp_sites in OSM I have c
sent from a phone
> On 14. Aug 2020, at 20:51, Hidde Wieringa wrote:
>
> Both tags allow tents, and both allow camper vans and caravans.
interesting, I would have expected a caravan site to not permit tents by
default.
Cheers Martin
___
Tagging m
sent from a phone
> On 14. Aug 2020, at 16:45, Paul Allen wrote:
>
> I wouldn't use this attribute on anything around here.
that’s fine. Apparently this attribute wasn’t created for an area like yours.
Nobody said you should use it. There are other areas in the world where these
are commo
sent from a phone
> On 14. Aug 2020, at 14:31, Mateusz Konieczny via Tagging
> wrote:
>
> If name of tunnel is also name of road then name tag should be fine.
how would you know whether the name is for the road or the tunnel if there is
only a name tag? What about setting both tags with th
sent from a phone
> On 14. Aug 2020, at 14:45, Mateusz Konieczny via Tagging
> wrote:
>
> Maybe outright recommending removal after trees are mapped would be even
> better?
vandalism. It’s like suggesting removing the lit tag after street lamps have
been added. Or some landuse after build
sent from a phone
> On 14. Aug 2020, at 16:00, Martin Koppenhoefer wrote:
>
> We are also mapping buildings and residential landuse and distinguishing
> residential roads.
or street lights and the lit property on roads.
C
sent from a phone
> On 14. Aug 2020, at 14:37, Volker Schmidt wrote:
>
> Apart from that I would not advocate "overlapping" mapping with three
> different schemes: individual trees a separate nodes, tree lines as separate
> ways, and the new proposal.
> On any given object there should never
sent from a phone
> On 14. Aug 2020, at 14:35, Paul Allen wrote:
>
> I still do not see a purpose for the attribute except as a convenient way
> of avoiding mapping tree rows.
routing. While it is not impossible to find tree lined roads by analyzing the
context, it is an expensive calculati
sent from a phone
> On 14. Aug 2020, at 13:13, Paul Allen wrote:
>
> What if the trees line only
> three of four sides? Or there aresome sizable gaps for the entrances?
indeed I would not suggest to use this on polygons, rather for linear features
like roads and waterways. I’m specificall
sent from a phone
> On 14. Aug 2020, at 13:28, Paul Allen wrote:
>
>> Martin Koppenhoefer wrote:
>>
>> Maybe it’s because I am not an English native speaker, but I would expect
>> something more than a head lice removal treatment place or a speech
>> th
sent from a phone
> On 14. Aug 2020, at 12:48, Paul Allen wrote:
>
> Some
> values that are far more specific like speech_therapist seem to have
> crept in that might be better as specialities.
>
> I'd say the facilities offering headlice removal and nothing else are as much
> clinics as are
sent from a phone
> On 14. Aug 2020, at 12:13, Jez Nicholson wrote:
>
> Q: if I mark a road as tree_lined=both and later map all the individual
> trees, do I remove the tree_lined=both tag as I now have finer detail?
as it is stated in the page, you should not do it. Having the individual t
sent from a phone
> On 14. Aug 2020, at 06:57, Peter Elderson wrote:
>
> I can see how an area such as a parking, a churchyard or pedestrian area can
> be tree lined.
I can also see this, but I’m not sure we should use this tag for it. Placement
on area (borders) will vary a lot, and it wo
I’ve set up an initial documentation page for the tree_lined attribute (used
mainly in conjunction with highways and waterways) and welcome comments for it:
https://wiki.openstreetmap.org/wiki/Key:tree_lined
This used to be a redirect to natural=tree_row (which is a different tag, as it
is for
sent from a phone
> On 13. Aug 2020, at 14:12, dktue wrote:
>
> the wiki states since more than eight years that there's a debate about
> wether one should tag "tunnel:name" or "name". [1]
>
> Is there any new opinion in the community on this topic that has not been
> documented in the wiki
sent from a phone
> On 12. Aug 2020, at 23:54, Lisbeth Salander wrote:
>
> Maybe
> healthcare=head_lice_removal would be more succinct?
+1
>
> As a bonus, that tag works both on its own and for hairdressers
> (shop=hairdresser + healthcare=head_lice_removal).
+1
> Map renderers should
sent from a phone
> On 12. Aug 2020, at 21:39, Yves wrote:
>
> Alexey, you're right, anyway physical properties like incline are better
> tagged on way than on relations.
and horizontal aerialways aren’t completely unheard of either. The incline
solution works only for a subset of aerialway
sent from a phone
> On 12. Aug 2020, at 14:26, Martin Koppenhoefer wrote:
>
>
>
> sent from a phone
>
>>> On 12. Aug 2020, at 13:55, Lisbeth Salander wrote:
>> For the
>> moment, I filled in general `healthcare` tags:
>> https://www.openstree
sent from a phone
>> On 12. Aug 2020, at 13:55, Lisbeth Salander wrote:
> For the
> moment, I filled in general `healthcare` tags:
> https://www.openstreetmap.org/node/7806359146
I agree with Paul that those which are also hairdressers should probably get an
additional property, although I w
sent from a phone
> On 11. Aug 2020, at 19:55, Clay Smalley wrote:
>
> We've pointed out concrete steps you can take to improve these
> initially-mapped stop positions. If mapping stop positions accurately is
> important to you, why not take responsibility for improving them?
I agree that
sent from a phone
> On 10. Aug 2020, at 15:11, Paul Allen wrote:
>
> If you disagree with that, then whichever of shop
> or amenity you think is the best fit to your cultural edge case and should
> therefore apply to all types of establishment in all countries, I want the
> other
> one. If y
sent from a phone
> On 10. Aug 2020, at 14:11, Paul Allen wrote:
>
> Not exactly. Shop fits where consumption is not allowed on the premises.
while it could be an indication, there isn’t such a strong rule that you could
tell from seeing a shop=* tag that consumption is never allowed at al
sent from a phone
> On 8. Aug 2020, at 19:37, Matthew Woehlke wrote:
>
> Well, perhaps it is clear to you and I, but I found a number of
> amenity=parking_space with capacity > 1 and no associated amenity=parking.
> *Someone* is using it wrong :-).
yes, what I intended was that amenity=par
sent from a phone
> On 8. Aug 2020, at 17:58, Paul Johnson wrote:
>
> Which honestly makes me surprised we have two separate amenities for parking
> already, since amenity=parking, access=no, bicycle=designated would be
> equivalent to amenity=bicycle_parking, and would make it easier to des
sent from a phone
> On 8. Aug 2020, at 14:26, Jo wrote:
>
> You could add all.
WRT mapping the stop position I agree that adding them all would make sense.
For the connection relation I believe it is not manageable to record and
maintain this level of detail, and the practical gain is ver
sent from a phone
> On 8. Aug 2020, at 14:48, Jan Michel wrote:
>
>> features, either bicycle or motorcycle and scooter parkings.
>
>
> I already proposed two options. You didn't like either.
>
> amenity=parking + vehicle=no + motorcycle=yes + kick_scooter(*)=ye
this doesn’t allow for bic
sent from a phone
> On 8. Aug 2020, at 13:46, Jan Michel wrote:
>
> If I just enter 'scooter parking' into Google Image Search, I find plenty
> examples of designated parking areas for both bicycles and scooters combined.
> There are also some moped/mofa parkings that allow (kick-)scooters t
sent from a phone
> On 7. Aug 2020, at 15:51, Paul Johnson wrote:
>
> I don't see what's not clear about access=* overriding all access not
> explicitly set.
+1, and that‘s also the reason why it should not be used
Cheers Martin ___
Tagging mail
I still believe shop=bubble_tea is suitable, as these are specific shops where
you can get only bubble tea. Although bubble tea is something to drink, I would
rather think of it as a specific kind of sweets, than as a shop where you can
get a beverage.
Amenity could also be suitable, if you pref
sent from a phone
> On 7. Aug 2020, at 15:47, Matthew Woehlke wrote:
>
> However, it sounds like you have this backwards; you are using
> amenity=parking_space to map lots and amenity=parking to map individual
> spaces. There appears to be a modest amount of such backwards mapping, and it
>
sent from a phone
> On 7. Aug 2020, at 14:51, Matthew Woehlke wrote:
>
>> that’s almost 22k uses, it is already established and voting yes or no will
>> not change it
>
> Well, yes, voting "no" is probably not useful, but this is also the least
> "interesting" bit of the proposal. The purpo
sent from a phone
> On 7. Aug 2020, at 20:14, Jan Michel wrote:
>
> It might be useful to have two different top-level amenity tags for parking
> lots for large and small vehicles, but not one tag for every type of vehicle.
I would say it depends on the kind of parkings that are to be mappe
sent from a phone
> On 7. Aug 2020, at 19:12, Paul Johnson wrote:
>
> I feel like a data consumer unable to deal with access tagging is already
> broken in advance.
although we already use access like tags for parkings it should be noted that
being allowed to access is different to being a
sent from a phone
> On 7. Aug 2020, at 17:57, Jan Michel wrote:
>
> I propose to not introduce new top-level keys because they are not flexible
> enough. I'm very well aware that we have parking, bicycle_parking and
> motorcycle_parking already, but it just doesn't scale with the amount of
sent from a phone
> On 6. Aug 2020, at 22:54, Matthew Woehlke wrote:
>
> - To codify / make official the de-facto parking_space=disabled
that’s almost 22k uses, it is already established and voting yes or no will not
change it
> - To allow mapping motorcycle parking as part of a unified p
sent from a phone
> On 6. Aug 2020, at 23:18, Mateusz Konieczny via Tagging
> wrote:
>
> Using access tags access=yes/access=customers/access=private - it is
> not entirely clear. And in many cases place clearly offers customer
> service but nearly all office is still closed to outsiders. Sti
Am Mi., 5. Aug. 2020 um 23:21 Uhr schrieb Mike Thompson :
>
> However, access=yes is a pretty broad statement. There may be modes of
> transport not yet contemplated (or which the mapper, and even the land
> manager is not aware of) which in the future will be prohibited.
>
+1, "access=*" is a
sent from a phone
> On 4. Aug 2020, at 18:30, Colin Smale wrote:
>
> The status of the Gulf of Taranto is disputable as it appears to have no
> basis in international law.
it is indeed disputed by the UK, the US and maybe others, but according to the
Italian baseline it is completely in It
sent from a phone
> On 4. Aug 2020, at 17:24, Joseph Eisenberg wrote:
>
> Looking at the Phillipines and Indonesia, the baseline has very little
> relation to the physical geographical tide lines, since it merely connects
> the outer edges of islands in the archipelago.
>
> Similarly, in Ur
sent from a phone
> On 4. Aug 2020, at 11:44, Jez Nicholson wrote:
>
> Frederik asks, "was our voting process changed recently", to which I believe
> the answer is, "yes, abstentions are no longer included in the count"
The “new” process is also flawed, as a no vote can bring a proposal to
sent from a phone
> On 4. Aug 2020, at 11:16, Christoph Hormann wrote:
>
> It might actually be better to introduce the opposite rule - that
> yes-votes need to explain why they are willing to dismiss sustained
> critical voices in the discussion.
This is a good point, and it is also alrea
sent from a phone
> On 4. Aug 2020, at 14:16, Christoph Hormann wrote:
>
> Almost all of the arguments you bring up here are cultural or political
> in nature.
Christoph, I guess it could be seen from looking at the email headers or when
reading in a threaded view, but for the convenience
sent from a phone
> On 4. Aug 2020, at 09:59, Frederik Ramm wrote:
>
> Has this been used in other votes in the past?
the instructions have always stated that opposing votes should explain why they
are against it. In practice this is not a significant hurdle, because many
reasons go like
sent from a phone
> On 3. Aug 2020, at 23:57, Jmapb wrote:
>
> The official postal version of the street name may be tagged as
> `official_name`;
IMHO official_name is not a suitable tag for an officially unnamed road with an
official postal name. At least not around here, where streets get
sent from a phone
> On 3. Aug 2020, at 22:10, Tod Fitch wrote:
>
> Looking at wikipedia, it seems that “storm drain” is used in the UK, Canada
> and the US [1]. And there is an “inlet” [2] associated with it. What are the
> opinions using:
>
> storm_drain = inlet
I would suggest to use an
Am Mo., 3. Aug. 2020 um 11:06 Uhr schrieb Tom Pfeifer <
t.pfei...@computer.org>:
> Possibilities discussed were:
>
> service=parking_access
> service=main
> service=access
> service=major
apart "access", all of these seem better than "parking". My preference
would go to the more neutral "main"
sent from a phone
> On 3. Aug 2020, at 06:09, David Dean wrote:
>
> On the main parking road, I think we are largely in agreement that
> service=parking would be a good addition to OSM documentation (and is already
> in use throughout the world, as such).
if we need a specific service sub
501 - 600 of 6524 matches
Mail list logo
