Re: [Tagging] Feature Proposal - RFC - landuse=governmental

[Joseph Eisenberg]

Thanks for working on this proposal, Markus. I agree that it would be
useful to have an approved type of land use for the administrative offices
of governments.


However, I'm not sure that "governmental" is the best value for the landuse
key. I think there would be a risk of mappers finding this tag in the
editors and using it for all governnment-owned land, not just for
administrative offices. In North America, and in many developing countries,
the national or local government owns large areas of land, including
rangeland, forests, transportation facilities, and military areas, in
addition to land uses for government offices.


In North America, it is somewhat common to talk about "government land" or
more specifically, "Federal land," "State land", and "Municipal land". But
the only uses of "governmental land use" I've found are in phrases talking
about "governmental land use policy", "governmental land use regulations",
and "governmental land use decision making". In these cases, the phrase is
talking about governments regulating all types of land use, including
commercial, retail, residential and industrial.


For these reasons, I believe the current tag "landuse=civic_admin" or
"landuse=public_administration" are a little better. They are not perfect,
because "civic" isn't precisely correct for land used for national or
provincial government offices, but they are less ambiguous. If this
proposal is going to use a new tag, it should include something about the
administrative nature of the land, so that mappers are less likely to use
the tag incorrectly for other types of government-owned land.


Also, in the proposal, it is stated that this tag will not be used for
"Public service facilities"

What is the definition of a "public service facility" as opposed to "public
administration offices?"

For example, would the Department of Motor Vehicles be considered a public
service, or an administrative office?

What about the administrative headquarters of the Public Health Department?

These offices combine some administrative features and some public service
features.


Thanks! I hope this proposal will be approved once it is improved - Joseph


On Sun, Oct 14, 2018 at 7:26 AM SelfishSeahorse 
wrote:

> Hello everyone!
>
> I am proposing a new tag, landuse=governmental, for marking land that
> is used for governing:
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/landuse%3Dgovernmental
>
> Regards
> Markus
>
> ___
> 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] Feature Proposal - RFC - landuse=governmental

[SelfishSeahorse]

Hello everyone!

I am proposing a new tag, landuse=governmental, for marking land that
is used for governing:

https://wiki.openstreetmap.org/wiki/Proposed_features/landuse%3Dgovernmental

Regards
Markus

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

Re: [Tagging] Dispensing vs vending (Was: Combined waste/recycling bins)

[SelfishSeahorse]

On Sat, 13 Oct 2018 at 17:03, Martin Koppenhoefer
 wrote:
>
> > amenity=parcel_station
> > parcel_station:send=yes/no
> > parcel_station:receive=yes/no
>
>
> +1, would be fine for me.
> or amenity=parcel_machine?

I'm indifferent to the tag name. Other possibilities are parcel locker
or parcel terminal. Some statistics from Google:

"parcel locker": about 200.000 results
"parcel terminal": about 153.000 results
"parcel station": about 109.000 results
"parcel machine": about 41.400 results

Maybe parcel locker is the most descriptive one.

> I believe packstation is a trademark

In any case it seems that only DHL (Germany) uses this term. (I've
never heard it. They're called 'My Post 24' in CH.)

On Sat, 13 Oct 2018 at 17:40, Martin Koppenhoefer
 wrote:
>
> maybe it would be better to use more universally applicable tags like
> parcel:sending
> parcel:pickup

Good idea!

Regards
Markus

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

Re: [Tagging] Dispensing vs vending (Was: Combined waste/recycling bins)

[Martin Koppenhoefer]

>> amenity=parcel_station
>> parcel_station:send=yes/no
>> parcel_station:receive=yes/no


maybe it would be better to use more universally applicable tags like
parcel:sending 
parcel:pickup 


Cheers, Martin 



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

Re: [Tagging] Dispensing vs vending (Was: Combined waste/recycling bins)

[Martin Koppenhoefer]

sent from a phone

> On 12. Oct 2018, at 13:51, SelfishSeahorse  wrote:
> 
> amenity=parcel_station
> parcel_station:send=yes/no
> parcel_station:receive=yes/no


+1, would be fine for me.
or amenity=parcel_machine?

I believe packstation is a trademark

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

Re: [Tagging] Highway=track and piste:type=nordic, are we doing it right ?

[Tod Fitch]

In my part of the world I know of several highway=* that are closed in winter 
and used as nordic ski trails. Not just tracks, I can think of a few that are 
two lane paved roads used for general vehicular traffic in summer.

It makes no sense to me to have two OSM ways sharing the same nodes simply to 
satisfy the implementation of an editor. That is just about the same as 
“mapping for the renderer”. If iD can’t be fixed for this use case then it 
should not be used.

Cheers,
Tod

> On Oct 13, 2018, at 12:28 AM, yves  wrote:
> 
> I'd like it to be a genuine question and not attract judgements for a 
> particular editor.
> 
> For a long time, contributors map crosscountry skiing by adding piste:nordic 
> to existing highway=tracks when they follow them. That's about 66% of the 
> 68'000km of crosscountry ski trails mapped or 51165 ways.
> 
> I tried to add preset in iD editor [1] to make it easier for the contributors 
> to find the right tags for ski pistes. However, iD presets are exclusives, 
> thus if you select a highway=track and then use the 'piste' preset, the 
> highway tag is removed by the editor.
> 
> This behaviour is consistent with the good practice 'One feature, one OSM 
> element' [2], and I can hear the argument that separate geometries are easier 
> to map.After all I'd really like to attract more skiers into contributing. 
> But this is different than the mapping habits.
> 
> I'd like to hear more opinions about this, I guess the ski pistes are not the 
> only niche tags for which this question arises.
> 
> Here are the alternatives :
> 
>1) map ski pistes as separate geometries, even if they follow an existing 
> track
> 
>2) change iD behaviour, why not in a forked version.
> 
>3) accept that iD presets are not suited for this kind of mapping. Not my 
> preferred one, it's a great tool.
> 
> Yves
> 
> [2] Are preset tags exclusives?
> 
> https://github.com/openstreetmap/iD/issues/5398
> 
> [1] One_feature,_one_OSM_element
> 
> https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
> 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature proposal - Voting - Telecom local networks

[François Lacombe]

Hi all,

The vote on the telecom local networks proposal is now open.
https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_local_loop

It is proposed to use telecom=* to map some physical components of local
networks, between exchanges buildings and households or businesses, mainly
with wired landlines.
telecom=* may have several more values in the future as a general key. More
proposals will have to be written.
This will allow to slowly and carefully clean up man_made key of
telecommunication specific values.

This tagging model is provided as to map available information. Unavailable
data doesn't make it necessarily bad.
Tagging has been tested in France on both copper and fibre networks with no
known issues.

Feel free to express your opinion at the bottom of the page, all the best

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

Re: [Tagging] Opening hours too long for OSM

[Simon Poole]

Am 13.10.2018 um 13:36 schrieb Tobias Zwick:
> Oh, you are right. I am sorry. So that opening hours tool understands
> more than what is defined in the specification.

Everybody that has written a OH parser needs to add a non-strict mode in
one way or the other, or else you wouldn't be able to parse a large part
(~15%) of the existing strings that are meaningful.

See for example https://github.com/simonpoole/OpeningHoursParser (note
that a really strict mode would throw out quite a bit more).

Simon

>
> On 13/10/2018 12:35, Simon Poole wrote:
>>
>> Am 13.10.2018 um 00:46 schrieb Tobias Zwick:
>>> It is already part of the specification that "Mo-Fr 9-17" is possible.
>> Actually it isn't, see
>> https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification
>>
>> I don't think discussing changes to the opening_hours grammar is this
>> thread is a sensible thing to do, most of the changes proposed are not
>> unambigously parseable and would require us to rely even more on
>> heuristics than we do now to make sense of the values. There a small
>> number of additions that could make sense and make things easier
>> (seasons and some more variable holidays), but they tend to fit in to
>> the existing schema.
>>
>> Simon
>>
>>
>>> Alas, QA tools / the openinghours evaluation tool emit a warning in this
>>> case: "Time range without minutes specified. Not very explicit! Please
>>> use this syntax instead "9:00-17:00"."
>>> Not sure why that is not seen as explicit.
>>>
>>> On 12/10/2018 22:29, bkil wrote:
 That looks like a nice improvement.

 Additionally, I've always wondered why we need to enter :00 after
 every hour and zero pad the hours? The shops themselves usually post
 the opening hours as 9-17 - why can't we use this human friendly
 abbreviation? I don't feel that it would be that much harder to parse.
 (9-17h would also work for me) 9-17:30 and 9:30-17 are still
 unambiguous (though, the latter looks a bit uglier at first).

 I think this would greatly improve readability, make data entry faster
 and less error prone and shorten the field all at the same time.

 Is this fit for a proposal?

 On Fri, Oct 12, 2018 at 12:04 AM Robin Schneider  wrote:
> On 10/11/18 11:47 PM, Jmapb wrote:
>> On 10/11/2018 5:21 PM, Tobias Zwick wrote:
>>
>>> Hey there!
>>>
>>> So, a user of StreetComplete came across the following complicated
>>> opening hours for a shop (prettified):
>>>
>>> Jun-Sep: Mo-Sa 10:00-18:00;
>>> Jun-Sep: Su 10:00-12:00;
>>> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
>>> Nov-Mar: Sa 10:00-12:00;
>>> Apr-May: Mo-Fr 10:00-12:30,15:00-18:00;
>>> Apr-May: Sa 10:00-12:30;
>>> Apr-May: Su 10:00-12:00;
>>> Oct: Mo-Fr 10:00-12:30,15:00-18:00;
>>> Oct: Sa 10:00-12:30;
>>> Oct: Su 10:00-12:00
>>>
>>> Unfortunately, this does not fit into the opening_hours value, as this
>>> is limited to 255 characters. What can we do?
> Hey :)
>
> I would say your best bet is to try to shorten the opening_hours values 
> using
> every little trick that the syntax has to offer, for example you can join 
> the
> month ranges which is enough to bring you under 255 characters.
>
> Jun-Sep: Mo-Sa 10:00-18:00;
> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00,15:00-17:00;
> Nov-Mar: Sa 10:00-12:00;
> Apr-May,Oct: Mo-Fr 10:00-12:30,15:00-18:00;
> Apr-May,Oct: Sa 10:00-12:30;
> Apr-May,Jun-Oct: Su 10:00-12:00
>
> You can then use the "value to compare to the first value:" feature of
> https://openingh.ypid.de/evaluation_tool/ to check that you still 
> preserved the
> original meaning.
>
> I don’t have much to add in case you can not bring the value under 255 
> only that
> I also don’t know any software which would handle that. I guess having the
> special cases in an additional tag and `opening_hours` fully valid would 
> be best
> then.
>
> opening_hours=Jun-Sep: Mo-Sa 10:00-18:00; Su10:00-12:00; Nov-Mar:
> Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00; Sa 10:00-12:00; Apr-May: Mo-Fr
> 10:00-12:30,15:00-18:00; Sa 10:00-12:30; Su 10:00-12:00; Oct: Mo-Fr
> 10:00-12:30,15:00-18:00; Sa 10:00-12:30;Oct: Su 10:00-12:00
>
> This won’t work. I had an idea for doing that but this is not supported 
> yet:
> https://github.com/opening-hours/opening_hours.js#todo
>
> --
> Live long and prosper
> Robin `ypid` Schneider -- https://me.ypid.de/
>
> ___
> 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

Re: [Tagging] Opening hours too long for OSM

[Tobias Zwick]

Oh, you are right. I am sorry. So that opening hours tool understands
more than what is defined in the specification.

On 13/10/2018 12:35, Simon Poole wrote:
> 
> 
> Am 13.10.2018 um 00:46 schrieb Tobias Zwick:
>> It is already part of the specification that "Mo-Fr 9-17" is possible.
> 
> Actually it isn't, see
> https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification
> 
> I don't think discussing changes to the opening_hours grammar is this
> thread is a sensible thing to do, most of the changes proposed are not
> unambigously parseable and would require us to rely even more on
> heuristics than we do now to make sense of the values. There a small
> number of additions that could make sense and make things easier
> (seasons and some more variable holidays), but they tend to fit in to
> the existing schema.
> 
> Simon
> 
> 
>> Alas, QA tools / the openinghours evaluation tool emit a warning in this
>> case: "Time range without minutes specified. Not very explicit! Please
>> use this syntax instead "9:00-17:00"."
>> Not sure why that is not seen as explicit.
>>
>> On 12/10/2018 22:29, bkil wrote:
>>> That looks like a nice improvement.
>>>
>>> Additionally, I've always wondered why we need to enter :00 after
>>> every hour and zero pad the hours? The shops themselves usually post
>>> the opening hours as 9-17 - why can't we use this human friendly
>>> abbreviation? I don't feel that it would be that much harder to parse.
>>> (9-17h would also work for me) 9-17:30 and 9:30-17 are still
>>> unambiguous (though, the latter looks a bit uglier at first).
>>>
>>> I think this would greatly improve readability, make data entry faster
>>> and less error prone and shorten the field all at the same time.
>>>
>>> Is this fit for a proposal?
>>>
>>> On Fri, Oct 12, 2018 at 12:04 AM Robin Schneider  wrote:
 On 10/11/18 11:47 PM, Jmapb wrote:
> On 10/11/2018 5:21 PM, Tobias Zwick wrote:
>
>> Hey there!
>>
>> So, a user of StreetComplete came across the following complicated
>> opening hours for a shop (prettified):
>>
>> Jun-Sep: Mo-Sa 10:00-18:00;
>> Jun-Sep: Su 10:00-12:00;
>> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
>> Nov-Mar: Sa 10:00-12:00;
>> Apr-May: Mo-Fr 10:00-12:30,15:00-18:00;
>> Apr-May: Sa 10:00-12:30;
>> Apr-May: Su 10:00-12:00;
>> Oct: Mo-Fr 10:00-12:30,15:00-18:00;
>> Oct: Sa 10:00-12:30;
>> Oct: Su 10:00-12:00
>>
>> Unfortunately, this does not fit into the opening_hours value, as this
>> is limited to 255 characters. What can we do?
 Hey :)

 I would say your best bet is to try to shorten the opening_hours values 
 using
 every little trick that the syntax has to offer, for example you can join 
 the
 month ranges which is enough to bring you under 255 characters.

 Jun-Sep: Mo-Sa 10:00-18:00;
 Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00,15:00-17:00;
 Nov-Mar: Sa 10:00-12:00;
 Apr-May,Oct: Mo-Fr 10:00-12:30,15:00-18:00;
 Apr-May,Oct: Sa 10:00-12:30;
 Apr-May,Jun-Oct: Su 10:00-12:00

 You can then use the "value to compare to the first value:" feature of
 https://openingh.ypid.de/evaluation_tool/ to check that you still 
 preserved the
 original meaning.

 I don’t have much to add in case you can not bring the value under 255 
 only that
 I also don’t know any software which would handle that. I guess having the
 special cases in an additional tag and `opening_hours` fully valid would 
 be best
 then.

 opening_hours=Jun-Sep: Mo-Sa 10:00-18:00; Su10:00-12:00; Nov-Mar:
 Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00; Sa 10:00-12:00; Apr-May: Mo-Fr
 10:00-12:30,15:00-18:00; Sa 10:00-12:30; Su 10:00-12:00; Oct: Mo-Fr
 10:00-12:30,15:00-18:00; Sa 10:00-12:30;Oct: Su 10:00-12:00

 This won’t work. I had an idea for doing that but this is not supported 
 yet:
 https://github.com/opening-hours/opening_hours.js#todo

 --
 Live long and prosper
 Robin `ypid` Schneider -- https://me.ypid.de/

 ___
 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
> 
> 
> 
> 
> ___
> 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] Opening hours too long for OSM

[Simon Poole]

Am 13.10.2018 um 00:46 schrieb Tobias Zwick:
> It is already part of the specification that "Mo-Fr 9-17" is possible.

Actually it isn't, see
https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification

I don't think discussing changes to the opening_hours grammar is this
thread is a sensible thing to do, most of the changes proposed are not
unambigously parseable and would require us to rely even more on
heuristics than we do now to make sense of the values. There a small
number of additions that could make sense and make things easier
(seasons and some more variable holidays), but they tend to fit in to
the existing schema.

Simon


> Alas, QA tools / the openinghours evaluation tool emit a warning in this
> case: "Time range without minutes specified. Not very explicit! Please
> use this syntax instead "9:00-17:00"."
> Not sure why that is not seen as explicit.
>
> On 12/10/2018 22:29, bkil wrote:
>> That looks like a nice improvement.
>>
>> Additionally, I've always wondered why we need to enter :00 after
>> every hour and zero pad the hours? The shops themselves usually post
>> the opening hours as 9-17 - why can't we use this human friendly
>> abbreviation? I don't feel that it would be that much harder to parse.
>> (9-17h would also work for me) 9-17:30 and 9:30-17 are still
>> unambiguous (though, the latter looks a bit uglier at first).
>>
>> I think this would greatly improve readability, make data entry faster
>> and less error prone and shorten the field all at the same time.
>>
>> Is this fit for a proposal?
>>
>> On Fri, Oct 12, 2018 at 12:04 AM Robin Schneider  wrote:
>>> On 10/11/18 11:47 PM, Jmapb wrote:
 On 10/11/2018 5:21 PM, Tobias Zwick wrote:

> Hey there!
>
> So, a user of StreetComplete came across the following complicated
> opening hours for a shop (prettified):
>
> Jun-Sep: Mo-Sa 10:00-18:00;
> Jun-Sep: Su 10:00-12:00;
> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
> Nov-Mar: Sa 10:00-12:00;
> Apr-May: Mo-Fr 10:00-12:30,15:00-18:00;
> Apr-May: Sa 10:00-12:30;
> Apr-May: Su 10:00-12:00;
> Oct: Mo-Fr 10:00-12:30,15:00-18:00;
> Oct: Sa 10:00-12:30;
> Oct: Su 10:00-12:00
>
> Unfortunately, this does not fit into the opening_hours value, as this
> is limited to 255 characters. What can we do?
>>> Hey :)
>>>
>>> I would say your best bet is to try to shorten the opening_hours values 
>>> using
>>> every little trick that the syntax has to offer, for example you can join 
>>> the
>>> month ranges which is enough to bring you under 255 characters.
>>>
>>> Jun-Sep: Mo-Sa 10:00-18:00;
>>> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00,15:00-17:00;
>>> Nov-Mar: Sa 10:00-12:00;
>>> Apr-May,Oct: Mo-Fr 10:00-12:30,15:00-18:00;
>>> Apr-May,Oct: Sa 10:00-12:30;
>>> Apr-May,Jun-Oct: Su 10:00-12:00
>>>
>>> You can then use the "value to compare to the first value:" feature of
>>> https://openingh.ypid.de/evaluation_tool/ to check that you still preserved 
>>> the
>>> original meaning.
>>>
>>> I don’t have much to add in case you can not bring the value under 255 only 
>>> that
>>> I also don’t know any software which would handle that. I guess having the
>>> special cases in an additional tag and `opening_hours` fully valid would be 
>>> best
>>> then.
>>>
>>> opening_hours=Jun-Sep: Mo-Sa 10:00-18:00; Su10:00-12:00; Nov-Mar:
>>> Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00; Sa 10:00-12:00; Apr-May: Mo-Fr
>>> 10:00-12:30,15:00-18:00; Sa 10:00-12:30; Su 10:00-12:00; Oct: Mo-Fr
>>> 10:00-12:30,15:00-18:00; Sa 10:00-12:30;Oct: Su 10:00-12:00
>>>
>>> This won’t work. I had an idea for doing that but this is not supported yet:
>>> https://github.com/opening-hours/opening_hours.js#todo
>>>
>>> --
>>> Live long and prosper
>>> Robin `ypid` Schneider -- https://me.ypid.de/
>>>
>>> ___
>>> 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




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Opening hours too long for OSM

[19b350d2-b1b3-4edb-ad96-288ea1238eee]

Are you sure?

Google allows to upload special hours via spreadsheet: https://support.google.com/business/answer/6303076?hl=en.


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

Re: [Tagging] highway=crossing used on ways

[Mateusz Konieczny]

12. Oct 2018 09:25 by gpetermann_muenc...@hotmail.com 
:

> In November 2015 I fix nearly all such ways, since then the number increased 
> again to 488. I don't know about iD, but JOSM prints a warning
> when you use this tagging, still many edits were made with JOSM. I wonder if 
> that means that we should accept highway=crossing as a shortcut for 
> highway=footway + footway=crossing?
>







How many highway=crossing on ways were added since  November 2015?




How many highway=crossing on nodes were added since  November 2015?




Without that it is hard to say anything.

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

Re: [Tagging] Opening hours too long for OSM

[Mateusz Konieczny]

I prefer to not use OSM tags for retaliating against anything.

12. Oct 2018 12:21 by 61sundow...@gmail.com :


> If they are going to make it complex ... retaliate and make it simple?
>___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Opening hours too long for OSM

[Mateusz Konieczny]

I am not sure why you opened 
https://github.com/opening-hours/opening_hours.js/issues/270 
to discuss new 
tagging idea.
If you want to discuss new tagging ideas then post it on a tagging mailing 
listor on OSM wiki discussion page.
 
13. Oct 2018 00:20 by allroadswo...@gmail.com :


> https://github.com/opening-hours/opening_hours.js/issues/270 
> 
> Thinking loud, I like a set of subcategories.
> Basic set for a year, others for the fast change.
> I find this a practical understandable solution. 
> From: OSMDoudou Sent: Friday, October 12, 2018 5:22 PM To: 'Tag discussion, 
> strategy and related tools' Subject: Re: [Tagging] Opening hours too long for 
> OSM 
> As to improving (thinking out loud here...), ..
>
> ___
> 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] Highway=track and piste:type=nordic, are we doing it right ?

[Mateusz Konieczny]

13. Oct 2018 09:28 by yve...@mailbox.org :


> For a long time, contributors map crosscountry skiing by adding piste:nordic 
> to existing highway=tracks when they follow them. That's about 66% of the 
> 68'000km of crosscountry ski trails mapped or 51165 ways.
>
> I tried to add preset in iD editor [1] to make it easier for the contributors 
> to find the right tags for ski pistes. However, iD presets are exclusives, 
> thus if you select a highway=track and then use the 'piste' preset, the 
> highway tag is removed by the editor.
>
> This behaviour is consistent with the good practice 'One feature, one OSM 
> element'

 

Are crosscountry skiing tracks following tracks as in




- (1) geometry is roughly similar but skiing track has separate geometry




of 





- (2) geometry is exactly the same as highway=track is sometimes changed into 
skiing track

or is used both as skiing track and road for accessing forest/field





In case of (1) skiing track should be mapped as a separate object as it is a 
separate object




In case of (2) skiing track and road is the same object and should be mapped as


the same geometry.





>  [2], and I can hear the argument that separate geometries are easier to map.




Is there a separate geometry?


 

> I'd like to hear more opinions about this, I guess the ski pistes are not the 
> only niche tags for which this question arises.
>




There are similar cases with streams.




There are two cases




- (1) highway=track is closely following waterway=stream (separate geometries)

- (2) waterway=stream riverbed is used also as access road

  - it may be also described as extremely long for


Main difference is that (AFAIK) situation "given object is both road and 
riverbed" is

quite rare and "given object is both forest road and skiing track" is more 
common.

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

Re: [Tagging] Opening hours too long for OSM

[Michał Brzozowski]

On Fri, Oct 12, 2018 at 8:44 PM Simon Poole  wrote:

>
> It is all fine and dandy for us to abstractly discuss such things, it is
> another to explain to Josephine mapper that no, the opening hours of the
> shop you want to map are one character too long and you need to map less
> detail. I just don't believe that "map less detail" is a concept that
> you will be able to convey to a majority of contributors and trying to
> do is likely futile.  The trend is simply the consequence of progressing
> from the rough to the detailed.
>
>
>
All the while other map providers (e.g. Google) don't bother to have
something more than static hours that are  identical every week.


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

[Tagging] Highway=track and piste:type=nordic, are we doing it right ?

[yves]

I'd like it to be a genuine question and not attract judgements for a 
particular editor.


For a long time, contributors map crosscountry skiing by adding 
piste:nordic to existing highway=tracks when they follow them. That's 
about 66% of the 68'000km of crosscountry ski trails mapped or 51165 ways.


I tried to add preset in iD editor [1] to make it easier for the 
contributors to find the right tags for ski pistes. However, iD presets 
are exclusives, thus if you select a highway=track and then use the 
'piste' preset, the highway tag is removed by the editor.


This behaviour is consistent with the good practice 'One feature, one 
OSM element' [2], and I can hear the argument that separate geometries 
are easier to map.After all I'd really like to attract more skiers into 
contributing. But this is different than the mapping habits.


I'd like to hear more opinions about this, I guess the ski pistes are 
not the only niche tags for which this question arises.


Here are the alternatives :

   1) map ski pistes as separate geometries, even if they follow an 
existing track


   2) change iD behaviour, why not in a forked version.

   3) accept that iD presets are not suited for this kind of mapping. 
Not my preferred one, it's a great tool.


Yves

[2] Are preset tags exclusives?

https://github.com/openstreetmap/iD/issues/5398

[1] One_feature,_one_OSM_element

https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element



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