Add camp_site field to tourism=camp_site

[osmuser63783]

This pull request is ready for review following a community forum discussion on the topic.

Description, Motivation & Context

tourism=camp_site is used to map anything from a signposted spot where a tent can be pitched, without any facilities, to luxury glamping sites. The proposal for camp_site= which introduced a categorisation scheme was accepted in 2015. In a community forum discussion about camp_site=basic it was pointed out that this tag isn't included in the iD preset, so here's a PR for adding it.

Testing help…

Overpass Turbo link

[github-actions]

🍱 You can preview the tagging presets of this pull request here.

[tyrasd]

Thanks for this! I would only say that the strings are a bit too long for the combo field labels (the labels would often be truncated). See inline for two possible ways to shorten them.

[osmuser63783]

Thanks for this! I would only say that the strings are a bit too long for the combo field labels (the labels would often be truncated). See inline for two possible ways to shorten them.

Thanks, I have committed your second suggestion.

[osmuser63783]

Hi, is anything else required? I am not quire sure how the Github PR review process works - I committed one of your suggestions, but it's still showing as "changes requested". Please let me know if there is anything else you would like me to do :-)

[tordans]

Testing

Looks good to me.

Notes

I found quite a few camp sites that do not have a preset when viewed in iD Query https://overpass-turbo.eu/s/1PW2

https://pr-1286--ideditor-presets-preview.netlify.app/id/dist/#background=Bing&disable_features=boundaries&id=n1280097225&locale=en&map=19.09/50.54228/14.02116 for example.

I wonder if that might be something to look into with a MapRoulette challenge …

[tordans]

Hi, is anything else required? I am not quire sure how the Github PR review process works - I committed one of your suggestions, but it's still showing as "changes requested". Please let me know if there is anything else you would like me to do :-)

In general, #1286 (comment) was the right next step and then wait for someone to find the time to do a second review.

For me, a review goes a lot faster the more I understand what is going on and have links (and screenshots) provided by others from the community to quickly go where I should look… Sometimes those are ideal with before and after views (screenshot/links). I tried going making this more formal with the new PR template that you will see with your next PR.

[tordans]

@tyrasd I think you will need to have to squash-merge this. I cannot for some reason. It looks like once you reviewed it, you also have to approve it? I expected my review to be enough in combination with your review comment being "resolved" but it seems not…
Could you check the rules if there is something that can be adjusted?

This is what the UI looks like for me:

---

@osmuser63783 we will have to wait for Martin to merge this one.

[osmuser63783]

Notes

I found quite a few camp sites that do not have a preset when viewed in iD Query https://overpass-turbo.eu/s/1PW2

https://pr-1286--ideditor-presets-preview.netlify.app/id/dist/#background=Bing&disable_features=boundaries&id=n1280097225&locale=en&map=19.09/50.54228/14.02116 for example.

I wonder if that might be something to look into with a MapRoulette challenge …

Thanks!

The ones in your Overpass query have a lifecycle prefix, in this case demolished:tourism=camp_site, which iD doesn't support. So no action necessary there I think.

The one in the second link has camp_site=reception which is not part of the approved classification scheme for camp sites, just an unrelated use of the same key from an abandoned proposal.

[osmuser63783]

Btw when I created the PR in a branch in my fork, I accidentally based in on the wrong version of the repo. So I rebased it, which involved the force-pushing that you can see here in the PR history. I guess the moment you squash everything into one commit this doesn't matter?

[tordans]

Btw when I created the PR in a branch in my fork, I accidentally based in on the wrong version of the repo. So I rebased it, which involved the force-pushing that you can see here in the PR history.

All good IMO. Force-push is always OK in those PRs IMO.

I guess the moment you squash everything into one commit this doesn't matter?

Yes. I would merge commit in cases where the commits have a meaningful structure and its helpful to look at them separately. Otherwise the squash is the quick way to cleanup the PR.