Re: [Tagging] [Talk-us] New MapRoulette Challenge - Add Surface to Highways

[Casper Kersten]

That's just wishful thinking. They all came up with Overture Maps precisely
to focus on a more data-driven approach and avoid the whole
community-consensus debate. If they wanted a round-table talk with us, they
would have organised it themselves long ago.

Just take their MR challenges for what they are: MR challenges. If you
happen to feel like mapping some motorway surfaces, then both the OSM
community and users like TomTom will be happy with your contributions. If
not, then do whatever else you enjoy doing.

Op za 4 feb. 2023 om 16:32 schreef Greg Troxel :

> "Brian M. Sperlongano"  writes:
>
> > I am asking for TomTom to be straight with us and answer why they're so
> > gung ho about missing surface tagging on motorways. Despite the negative
> > reaction in the US, it seems that they're intent on spamming this
> nonsense
> > challenge worldwide, and they *refuse to answer why they're asking the
> > community to focus on this*.
>
> I also asked "please explain how you use osm data and how that is
> compliant with the license", and didn't see an answer.
>
> Perhaps OSMF-US should approach TomTom management (and other companies)
> to talk about the general issues of how companies interact with the
> community.
>
> ___
> 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] [Talk-us] New MapRoulette Challenge - Add Surface to Highways

[Casper Kersten]

TomTom has created the same challenge for the Netherlands:
https://maproulette.org/browse/challenges/37471

Just days before that challenge was created, I had a discussion on Discord
with some other Dutch mappers. I thought it would be easy to tag all
remaining highway=motorway without a surface tag in NL with
surface=asphalt, since 81% already had this tag and there were no other
surface tags present (except a handful on highway=motorway_link). I was
quickly proven wrong as one mapper then found a bridge with a concrete
surface and tagged it accordingly. It may be the only highway=motorway
section in NL, but it demonstrates that my assumption that everything was
asphalt was wrong and there is some merit in tagging the surface
explicitly.

I don't see what's wrong with these MR challenges by TomTom. Of course you
can totally ignore them if all you care about is paved / unpaved, but if
you want to know more specifics, then explicitly tagged surfaces on
motorways still have some value.

Op vr 3 feb. 2023 om 13:17 schreef Walker Kosmidou-Bradley <
walker.t.brad...@gmail.com>:

> Thanks Andy,
>
> We do use country default values and other customizations. I didn’t really
> want to unpack the entire methodology. The point is the more attribution we
> have, the easier and faster it is to conduct replicable analysis around the
> world. It helps from a coding perspective, even if the attribution might
> not make that much sense for any single country.
>
> It just seems strange that people would complain about others adding
> specificity of attributes. If the data is not wrong, and as it not
> impacting you who cares? If you don’t want to do those tasks in
> MapRoulette, don’t. We all contribute to and interact with OSM data in
> different ways. If someone wants to go mark every species of tree, awesome.
> If others mark the smoothness of roads, awesome. That’s how the community
> works. Something might not make sense to me, but I’m sure it makes sense to
> the person making the task.
>
> Best,
>
> Walker KB
>
> > On Feb 3, 2023, at 11:27, Andy Townsend  wrote:
> >
> > On 2/3/23 09:16, Walker Kosmidou-Bradley wrote:
> >
> >> I use routing to measure accessibility to schools and health clinics
> here in west Africa. I have to make sure that my models also work in South
> Asia. Having the surface tag attributed makes processing infinitely easier
> because I don’t have to adjust my default values based on country.
> >
> > (veering off from TomTom's MapRoulette challenge somewhat, but)
> >
> > Unfortunately, you will have to adjust your default values based on
> country.  There are enough differences even between mapping approaches in
> nearby western European countries that a router will produce nonsensical
> results if it makes assumptions valid only in place A in place B as well.
> >
> > Also, even if someone filled in all the values for an "obvious" tag
> (perhaps in response to a MapRoulette challenge such as this one), there's
> no guarantee that new motorways would have the same tag added in the
> future, or that the tag would remain as more detail is added.
> >
> > That said - sometimes values that are "obvious" in one place aren't
> "obvious" in another, so it's definitely worth having the discussion about
> that if it's relevant (which as numerous people have said previously, it
> isn't for this challenge in the US.
> >
> > Best Regards,
> >
> > Andy
> >
> >
> >
> > ___
> > 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] Best practices for creating a categorical key=value

[Casper Kersten]

@Daniel Bégin
You're welcome. Good luck and happy mapping!

Op wo 18 jan. 2023 om 23:45 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

>
>
> sent from a phone
>
> > On 18 Jan 2023, at 19:25, Daniel Bégin  wrote:
> >
> > I just wrote:  “I used office=construction_company because it's the only
> related tag in the wiki (Key:office).”
>
>
> +1, sorry hadn’t seen the rest of the conversation, for offices “office”.
>
>  The landuse would be commercial in this case or industrial for production
> sites.
> ___
> 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] Best practices for creating a categorical key=value

[Casper Kersten]

@Marc_marc You make a good point, but I see it more as a way of linking
tags, as you suggested before.

That said, I hadn't noticed that the tag office=construction_company is
already documented and in use, so I guess that would be a good tag to use.
* https://wiki.openstreetmap.org/wiki/Tag%3Aoffice%3Dconstruction_company
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Best practices for creating a categorical key=value

[Casper Kersten]

Hello. I suggest that you have a good look at the following pages:
* https://wiki.openstreetmap.org/wiki/Any_tags_you_like
* https://wiki.openstreetmap.org/wiki/User:Joto/How_to_invent_tags

Going through a proposal process isn't always necessary; you can just
document your tag and give it the status "in use".

For this specific case I recommend using the tags office=company +
company=construction, which are already documented:
* https://wiki.openstreetmap.org/wiki/Tag:office%3Dcompany
* https://wiki.openstreetmap.org/wiki/Tag%3Acompany%3Dconstruction

Personally I wouldn't tag on the office that a company specifically trades
precast concrete.
This information fits better on a man_made=works as product=*, on the
location where it is produced.
* https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dworks
* https://wiki.openstreetmap.org/wiki/Key:product
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Relations of type=site + tourism=camp_site

[Casper Kersten]

Site relations are usually completely redundant if you just tag an
operator=* tag. A tourism=camp_site closed way or multipolygon is,
of course, a camp site, and a shop or parking area on or belonging to
that camp site should get an operator=* tag with the same tag value as the
name or operator of the camp site.

Grouping the tourism=camp_site area and all objects related to that camp
site in a site relation and calling that a camp site as a whole is a clear
violation of the One feature, one OSM element guideline, as the
tourism=camp_site is already the element for the camp site and the site
relation would unnecessarily duplicate that.

Op vr 11 nov. 2022 om 10:55 schreef Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

>
>
>
> Nov 10, 2022, 21:49 by li...@fuchsschwanzdomain.de:
>
> Yves via Tagging  wrote:
>
> Site relations are often used to models thing that aren't spatially
> joined, like windfarms, universities... I can easily imagine it's
> reasonable to use them for campings in some corner cases where a single
> area doesn't work.
>
>
> Yes, let me clarify this with an example:
>
> E.g. This site has a working site relation (without tourism=camp_site
> removed):
>
> https://opencampingmap.org/#15/49.0815/7.9123/1/1/bef/node/3824691120
>
> The camp_site node is https://www.openstreetmap.org/node/3824691120
> Site relation is https://www.openstreetmap.org/relation/13009876
>
> While it is currently tagged toilets=yes and openfire=yes this is not
> mandatory because evaluating the corresponding site relation will give us a
> toilet and a fireplace.
>
> So what I do with site relations here is basically the same I do with
> camp_site areas. With areas I check if any supported object is inside the
> area (spatial join) and assume that this is a feature of this particular
> camp_site.
>
> With site-relations this is even easier as I can consider all objects
> related to the site a feature of the camp-site in the relation.
>
> I think this is elegant especially in comparison to the alternatives
> suggested here like expanding the campsite polygon into areas open to the
> general public like reception desks, restaurants or even toilets also used
> by other facilities like sport-centers.
>
> obviously camp site should not be fakely expanded to cover nearby
> restaurants
>
> what about automatically detecting nearby restaurants/toilets and so on?
> rater than listing them manually with site relation (optionally, check
> operator tag - that would apply only in cases where there are multiple
> camp sites or other objects each with access=customers objects)
>
> ___
> 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 - Approved - Citadels

[Casper Kersten]

I am pleased to announce that the proposal for `castle_type=citadel` has
been approved with ten votes for, 1 vote against and 1 abstention.
https://wiki.openstreetmap.org/wiki/Proposed_features/Citadel

I am now going to document the approved tag on the relevant Wiki page(s)
and then I'll probably tag a few citadels with it.

My thanks to everyone who has voted and/or contributed to discussions.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] improve the proposal procedure

[Casper Kersten]

@Marc_marc

- limit to 1 simultaneous proposal per person?

I oppose this idea. Sometimes people just have plenty of free time and good
ideas and use this to make and share proposals. I see no reason to hinder
them.

- limit this to active contributor status in the osmf sense?

I strongly oppose this. The OSMF does not control OSM and it should stay
that way. If people want to improve OSM without having to get directly
involved with the OSMF I see no reason to hinder them.

- encourage the use of the "resolved" tag in the talk page to see visually
if the points have been addressed or not?

I support this idea, but I would not make it mandatory. Sometimes proposals
are good enough, and not all issues can reasonably be resolved.

- improve the wording for the 14 day minimum time limit which is too often
understood lately as "pfff 14 days to wait" ?

Suggestions for this can be put forward on the Talk page of the "Proposal
process" Wiki page.

- limit the scope of proposal ?

I see no reason to do so. Recently the Belariusian community agreed to a
big change in how languages are tagged. What alternative platform for
discussing and voting on this would you offer them?

All this said, I do appreciate good quality proposals and constructive
discussions. I'm happy with all these creative proposals that are being put
forward. OSM isn't finished yet, after all.

Op do 20 okt. 2022 om 15:06 schreef Illia Marchenko <
illiamarchenk...@gmail.com>:

> I think that additional restrictions are unnecessary, unless proper reason.
>
> чт, 20 окт. 2022 г., 15:44 Peter Elderson :
>
>> I agree that it got a little out of hand, but there were some good
>> proposals and votes as well.
>> Proposing and voting should not be hard, so you always get some lesser
>> quality stuff.
>>
>> Let's not throw away the baby with the wash water.
>>
>>  Peter Elderson
>>
>>
>> Op do 20 okt. 2022 om 14:28 schreef Marc_marc :
>>
>>> Hello,
>>>
>>> the past few weeks have been stormy for proposals:
>>> - people opening 4 or more RFCs to collect opinions
>>> - RFCs or votes that open and close in less than 12 hours
>>> - Proposals that go to vote on the 14th day, even though
>>> this is the minimum time limit and the problems in progress
>>> have sometimes not been resolved.
>>> - nominees to make even more simultaneous proposals
>>> without showing that it is just one person
>>>
>>> How could we improve this ?
>>> - limit to 1 simultaneous proposal per person?
>>> - limit this to active contributor status in the osmf sense?
>>> - encourage the use of the "resolved" tag in the talk page
>>> to see visually if the points have been addressed or not?
>>> - improve the wording for the 14 day minimum time limit which
>>> is too often understood lately as "pfff 14 days to wait" ?
>>> - limit the scope of proposal ?
>>> - any other ideas?
>>>
>>> Regards,
>>> Marc
>>>
>>>
>>>
>>> ___
>>> 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] Feature proposal - RFC - Citadels

[Casper Kersten]

Voting is now open:
https://wiki.openstreetmap.org/wiki/Proposed_features/Citadel#Voting

Op ma 3 okt. 2022 om 22:53 schreef Casper Kersten :

> P.s. Citadels and fortresses were complementary for a city's defence, but
> do not always coexist. Also, some fortresses have been (partially)
> demolished but the citadel have been left largely intact, as is the case in
> Lille, France.
>
> Op ma 3 okt. 2022 om 22:49 schreef Casper Kersten <
> casperkerst...@gmail.com>:
>
>> @Martin Koppenhoefer That's a good question, and one I will surely
>> address on the proposal page.
>>
>> The short answer is that a fortress is the fortified city centre with its
>> city walls and defensive towers, and a citadel is a stand-alone
>> fortification inside or on the edge of it.
>>
>> A good example is Saint-Martin-de-Ré (
>> https://www.openstreetmap.org/#map=16/46.2026/-1.3657), where the
>> https://www.openstreetmap.org/relation/308616 is the fortress and
>> https://www.openstreetmap.org/way/35814333 is the citadel.
>>
>> https://wiki.openstreetmap.org/wiki/File:Vestingwerken_schema.svg shows
>> essentially the same thing.
>>
>> Op ma 3 okt. 2022 om 22:38 schreef Martin Koppenhoefer <
>> dieterdre...@gmail.com>:
>>
>>>
>>>
>>> Am Mo., 3. Okt. 2022 um 22:30 Uhr schrieb Casper Kersten <
>>> casperkerst...@gmail.com>:
>>>
>>>> I just created a proposal page to tag citadels:
>>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Citadel
>>>> The proposed tag is castle_type=citadel.
>>>>
>>>> All feedback is welcome. Feel free to share it here, but I prefer to
>>>> discuss the proposal on the Community Forum and on the discussion page on
>>>> the Wiki.
>>>>
>>>> https://community.openstreetmap.org/t/rfc-proposal-to-tag-citadels/3570
>>>>
>>>
>>>
>>> can you explain how it relates to
>>> https://wiki.openstreetmap.org/wiki/Tag:castle_type%3Dfortress ?
>>>
>>> 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] Feature Proposal - RFC - Historic

[Casper Kersten]

As I mentioned on the community forum, the historic=* key is full of tags
that should really need to be revisited, changed or redefined before they
can be voted on. I strongly advise against approving all historic=* tags en
masse.

Elaboration on the community forum:
https://community.openstreetmap.org/t/feature-proposal-rfc-historic/3910

Op di 11 okt. 2022 om 16:23 schreef Andy Townsend :

> On 11/10/2022 14:54, Anne-Karoline Distel wrote:
>
> Obviously, I support this. It has its own preset scheme in the iD editor,
> its own icons etc.
>
> The following are missing (of the top of my head, because I proposed them)
> from the list and were approved already:
>
> creamery 
>
> ogham stone
> 
> Anne
>
>
> I suspect that most editors' preset schemes aren't driven entirely by what
> tags are "approved" and what aren't.  iD has historically used previous
> usage, so for example values suggested for the key "building" match
> https://taginfo.openstreetmap.org/keys/building#values .  JOSM uses a
> different list of curated values, but defaults to what the current mapper
> has used most recently.
>
> For a new "historic" node, JOSM out of the box doesn't offer "creamery" or
> "ogham_stone", and it wouldn't really make sense for it to do so, since
> there are relatively few of either (even unmapped) around the world
> compared to the other historical suggestions already on JOSM's list.
>
> Best Regards,
>
> Andy
>
>
>
> ___
> 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] Feature proposal - RFC - Citadels

[Casper Kersten]

P.s. Citadels and fortresses were complementary for a city's defence, but
do not always coexist. Also, some fortresses have been (partially)
demolished but the citadel have been left largely intact, as is the case in
Lille, France.

Op ma 3 okt. 2022 om 22:49 schreef Casper Kersten :

> @Martin Koppenhoefer That's a good question, and one I will surely address
> on the proposal page.
>
> The short answer is that a fortress is the fortified city centre with its
> city walls and defensive towers, and a citadel is a stand-alone
> fortification inside or on the edge of it.
>
> A good example is Saint-Martin-de-Ré (
> https://www.openstreetmap.org/#map=16/46.2026/-1.3657), where the
> https://www.openstreetmap.org/relation/308616 is the fortress and
> https://www.openstreetmap.org/way/35814333 is the citadel.
>
> https://wiki.openstreetmap.org/wiki/File:Vestingwerken_schema.svg shows
> essentially the same thing.
>
> Op ma 3 okt. 2022 om 22:38 schreef Martin Koppenhoefer <
> dieterdre...@gmail.com>:
>
>>
>>
>> Am Mo., 3. Okt. 2022 um 22:30 Uhr schrieb Casper Kersten <
>> casperkerst...@gmail.com>:
>>
>>> I just created a proposal page to tag citadels:
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Citadel
>>> The proposed tag is castle_type=citadel.
>>>
>>> All feedback is welcome. Feel free to share it here, but I prefer to
>>> discuss the proposal on the Community Forum and on the discussion page on
>>> the Wiki.
>>>
>>> https://community.openstreetmap.org/t/rfc-proposal-to-tag-citadels/3570
>>>
>>
>>
>> can you explain how it relates to
>> https://wiki.openstreetmap.org/wiki/Tag:castle_type%3Dfortress ?
>>
>> 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] Feature proposal - RFC - Citadels

[Casper Kersten]

@Martin Koppenhoefer That's a good question, and one I will surely address
on the proposal page.

The short answer is that a fortress is the fortified city centre with its
city walls and defensive towers, and a citadel is a stand-alone
fortification inside or on the edge of it.

A good example is Saint-Martin-de-Ré (
https://www.openstreetmap.org/#map=16/46.2026/-1.3657), where the
https://www.openstreetmap.org/relation/308616 is the fortress and
https://www.openstreetmap.org/way/35814333 is the citadel.

https://wiki.openstreetmap.org/wiki/File:Vestingwerken_schema.svg shows
essentially the same thing.

Op ma 3 okt. 2022 om 22:38 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

>
>
> Am Mo., 3. Okt. 2022 um 22:30 Uhr schrieb Casper Kersten <
> casperkerst...@gmail.com>:
>
>> I just created a proposal page to tag citadels:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Citadel
>> The proposed tag is castle_type=citadel.
>>
>> All feedback is welcome. Feel free to share it here, but I prefer to
>> discuss the proposal on the Community Forum and on the discussion page on
>> the Wiki.
>>
>> https://community.openstreetmap.org/t/rfc-proposal-to-tag-citadels/3570
>>
>
>
> can you explain how it relates to
> https://wiki.openstreetmap.org/wiki/Tag:castle_type%3Dfortress ?
>
> 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

[Tagging] Feature proposal - RFC - Citadels

[Casper Kersten]

I just created a proposal page to tag citadels:
https://wiki.openstreetmap.org/wiki/Proposed_features/Citadel
The proposed tag is castle_type=citadel.

All feedback is welcome. Feel free to share it here, but I prefer to
discuss the proposal on the Community Forum and on the discussion page on
the Wiki.

https://community.openstreetmap.org/t/rfc-proposal-to-tag-citadels/3570
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging