User talk:JeroenHoek

Dog access

Thanks for spotting old unresolved discussion. I moved dog=* to "see also" section, as it is about entering with a dog - not about dog riding.

And as result it is neither horse=* equivalent (which is about horse rider access) nor subset of transport without a vehicle.

Again, thank you for your edit, hopefully you are OK with my change Mateusz Konieczny (talk) 09:28, 24 May 2020 (UTC)

Thanks for talk page review

Also, thanks for pointing out long response time. Thanks to your comment and reviewed the page and noticed request for examples, from 2009. I finally added them (at beginning of the page) Mateusz Konieczny (talk) 10:12, 24 May 2020 (UTC)

No problem. JeroenHoek (talk) 10:16, 24 May 2020 (UTC)

parking=street

Hey,

I have seen that you use and propose parking=street. I'm also mapping such things sometimes, but parking=lane is more often in use and a better value from a semantic point of view. I assume you mean these? There is also parking=layby in use which I use for parking "pockets" like this or this.--Supaplex030 (talk) 15:51, 22 September 2020 (UTC)

Hi, thanks for noticing. Your work in Berlin looks good.

I saw parking=lane, but it seems to be specifically about parking parallel along a street, being the explicitly mapped equivalent of parking:lane=*. It's not completely clear to me if parking=lane is only meant for explicitly marked (by lines or road layout) parking areas, or any roadside parking. I guess it makes sense for those parking areas directly parallel to the road where cars park in the same direction and orientation as the traffic flow.

I've looked at parking=layby too, but it seems to be mostly used for literal lay-by's (in the first sense of the word as defined here: “A paved area at the side of a highway designated for drivers to stop in, for emergency parking, or where vehicles can wait, with larger lay-bys possibly having facilities like food vendors or public telephones.”. That is, mostly (emergency) parking areas outside of settlements. It didn't seem right to use it for normal street-side parking, especially if the emergency parking nature of it is intended. Renderers might choose to render these more markedly than normal parking areas. A lack of documentation may be a problem here.

So I started using parking=street, because the mappers who already used that tag used it in the way I'm using it as well. I am working at some documentation to clarify this. I don't think having all three is problematic, but lay-by in particular may need some clarification in terms of documentation; especially if that tag serves to mark places where you can stop on a highway in case of emergencies. What I want to achieve eventually is to have tagging available that can be used by renderers to de-emphasize them compared to the other parking types. All the blue P's look silly for simple road-side parking, a smaller P or a suitable background colour would make the map much better, and make mappers less hesitant to map these areas. Of course the JOSM preset should have these too, so documentation is a first step.

What do you think?

(Example of a typical Dutch parking bay: https://www.openstreetmap.org/relation/11650954) (satellite view)

JeroenHoek (talk) 16:43, 22 September 2020 (UTC)

You are probably right: parking=layby was originally intended for a different kind of parking. I mean exactly the kind of parking you show. In German language there are several synonymous but clear terms for this ("Parkbucht", "Parktasche", "Parkhafen"), but I'm not sure how it is in the English language. Maybe "parking bay" is a suitable term (but according to Taginfo it is very rarely used).

I personally associate "street" too strongly with "lane". I almost never use parking=lane because I think the parking:lane=* scheme is absolutely sufficient for that, but I have seen some mappers who use it to map on-street-parking lanes separately (like this). "Lane" parking doesn't have to be parallel: here in Berlin it is often diagonal or perpendicular (as shown in the picture). I recently invented "lane:parking"/"layby:parking" = "parallel"/"diagonal"/"perpendicular" (according to the parking:lanes schema), so that the orientation is not lost in separately mapped street parking.

All in all you are right: As long as there is no documentation or broader discussion about it, different mappers will use it inconsistently according to their personal taste. We could continue this discussion on Talk:Key:parking or Tagging Mailing List and propose a value for "parking bays" or do some research on an English name?--Supaplex030 (talk) 18:47, 22 September 2020 (UTC)

'bay' refers to a single parking space, so 'bays' might work, but it might also lack something hinting at the primary characteristic of this type of parking. Not a bad idea to avoid street and lane though; I can always re-tag the parking areas in my area. parking=street_side might work perhaps?

I initially chose 'street' because I want to make it clear that these are street-side parking areas, distinct from parking=surface, which is a dedicated parking area usually off the main road, often for a specific purpose (shops etc.).

It might be best to prepare some sort of proposal or at least some background on the wiki before going to the tagging-ML though, in order to have concrete examples (with photo's) and a good explanation. JeroenHoek (talk) 19:18, 22 September 2020 (UTC)

+1. i will also search again for a suitable term. Do you know native English speakers who could help us with this? We should start a small proposal with background information and examples together and present it on the mailing list when the time comes...--Supaplex030 (talk) 19:39, 22 September 2020 (UTC)

Good idea. Helpful to have examples from two countries as well. JeroenHoek (talk) 17:06, 23 September 2020 (UTC)

Hey Jeroen, I gave the question about the term to some English (British) native speakers, which resulted in a funny discussion, but in the end they came to the conclusion that they don't know a specific term for it. In any case, I am using "Layby" incorrectly and will change it as soon as we have a better term. I think parking=street_side is quite good so far.

I also have a few photos of situations where I would use street_side (up to now "layby" in my case). I would define this kind of parking as an area suitable or designated for parking, which is directly adjacent to the street/roadway and is separated/interrupted by physical structures like curbs, curb extensions etc. (forming a kind of "pocket" or "bay"). In any case, this space could not be used continuously as a lane for driving if no vehicles were standing there (in contrast to parking=lane).

• 
• 
• 
• 

But I'm not sure yet how I would draw the line between "lane" and "street_side", because at least in my area there are often parking lanes, which are separated by a curb extension at the ends of the street (for example you can see it at this "curb line"). One possibility could be: If the road surface does not differ from the rest of the road, then this rather speaks for "lane". And if - apart from the two ends of the street - there are other "interruptions" (curbs/curb extensions, trees, street lamps, green verges...), then it is "street_side". (The length of the "pocket" or street is also relevant: If there is a interruption only at the beginning and at the end of a street, but the street is very short, a "pocket" is formed nevertheless.)

Here (OSM | Mapillary, left: street_side, right: lane) is another case where I used "street_side" [layby] and "lane" on the same street today: You could either use both tags together with "parking:lane" on the highway line or - especially the "street_side pockets" - map them as separate objects.

Would you agree with me so far - are we still talking about the same kind of parking lot? :) The example you have shown above is very clear, but I try to look for the edge cases to find a clear definition... --Supaplex030 (talk) 21:15, 27 September 2020 (UTC)

Another small example: This one would be surface instead of street_side for me, because it is not located directly next to a street but can only be reached via an service driveway. (Edit: But you could still add parking:surface=perpendicular to express the parking direction to the driveway. At least that's what I've been doing at street_side parking for a while now.)--Supaplex030 (talk) 21:24, 27 September 2020 (UTC)

Yes, I think we are quite aligned in what we consider parking=street_side (to give it a name for now, but I think it works). Examples of what I consider typical, clear-cut cases of this:

• 
• 
• 
• 

1 — 2 — 3 — 4

Now this one is perhaps a little bit less clear. There is separation from the carriageway, but cars overlap:

• 

Do I understand parking=lane correctly that it should be applied for cases where there is no delineation or markings at all, and people just park cars on the 'carriageway' (but usually following a locally established pattern of which side of the road to use; its quite odd to see that the side never changes somehow. I'll add a photo for that tomorrow.) This one example here above is probably parking=street_side, but I guess it edges into parking=lane territory the more it overlaps the carriageway? JeroenHoek (talk) 19:37, 28 September 2020 (UTC)

Since there is no definition for parking=lane anywhere, everybody uses it in his own way... (Maybe you have seen this note.) I rarely use it, here exceptionally, because I didn't want to divide the road into many pieces for parking:lane tagging, but I still wanted to precisely map the parking lanes due to unusually wide driveways. There are even markings at this place, but for me personally that would not be a criterion of relevance (only for mapping capacity=* on them).

You also found a nice edge case. I have never seen one like it before ;) My opinion: "lane" would be if the car would stand mostly on the road. (Or use "lane;street_side" as the equivalent of "parking:lane* = half_on_kerb"..?)

By the way: I use this OSM information in my area for parking space and "area fairness" analyses, so I'm always very interested in the most accurate data possible ;) (See image here and documentation here (unfortunately only in German so far))--Supaplex030 (talk) 10:14, 29 September 2020 (UTC)

Deutsch geht aber auch (zumindest lesen). Interessantes Projekt. :)

P.S. I like your precise micro-mappings, just my taste :)--Supaplex030 (talk) 10:20, 29 September 2020 (UTC)

Danke!

I'll see if I can write down my thoughts on this topic this weekend so we can work that into a draft proposal. Did you have anything written down yet? JeroenHoek (talk) 17:31, 30 September 2020 (UTC)

I have just set up a basis/skeleton/stub for the proposal and tried to come up with a definition (see Proposed features/parking=street side). I also hope that I will be able to give it some more thought over the weekend. Feel free to change everything I have already written there :) --Supaplex030 (talk) 19:28, 30 September 2020 (UTC)

I was not really aware until now that "lay_by" is the second most common use after "on_street" in the parking:lane scheme. Obviously this means chains of parking bays (as I enter them here in Berlin). Worldwide there are about 5,000 uses of this kind. (see http://overpass-turbo.eu/s/YHc)

Of course this is not a solution for single parking bays, as you can see on many of your pictures. But it makes me doubt if we really have to "invent something new" or if we should rather adapt this scheme to separately mapped areas... What do you think? Should we after all get an early feedback from the Tagging Mailing List?--Supaplex030 (talk) 09:14, 5 October 2020 (UTC)

Hmm. I guess we'd better ask. Do you want to take the lead on that? The documentation for lay_by on parking:lane=* is weird though. It links to https://en.wikipedia.org/wiki/Rest_area#Lay-bys (which describes the rural road-side parking area for short stops), but people use it for street-side parking areas… JeroenHoek (talk) 18:42, 5 October 2020 (UTC)

I can do that in the next few days. I am not sure yet what would be a good solution...--Supaplex030 (talk) 18:50, 5 October 2020 (UTC)

I have now restructured and supplemented the proposal in such a way that in my opinion it has actually reached a presentable state that could be discussed. In your new chapter about relations to other parking-values (very good section/useful illustration, by the way!) I made some additions, especially at "layby", to show ambiguities.

Is there an explicit term in the Dutch language for the form of parking we mean? I have added a reference to the German terms and it could be interesting if you know more.

You know, I'm not rightly sure. Aside from the plural of parking space (parkeervak, so parkeervakken). There is parkeerstrook for what is essentially a parking-lane, and in more GIS-centered documentation there is parkeervlak. I think most people just say parkeervakken, or even the singular parkeervak to refer to the whole section. I'll ask the Dutch OSM-community. JeroenHoek (talk) 07:51, 11 October 2020 (UTC)

Maybe we could start an "official" RFC with this in the next days - or what do you think? Is it already ready for a broader discussion? --Supaplex030 (talk) 21:27, 10 October 2020 (UTC)

Yes, I think it is almost ready. Though I would like to add a graphic similar to those in the parking-value section, but more general for the proposal section showing the types of areas intended for this tag. I'll see if I can finish that. JeroenHoek (talk) 07:51, 11 October 2020 (UTC)

Nice graphic! I made it a little bit smaller and right-aligned - is that ok? So that it doesn't seem so dominant. How do you create these graphics, is it a mapping style or do you draw them yourself?

If you don't mind, I can start a first RFC soon?--Supaplex030 (talk) 19:41, 20 October 2020 (UTC)

Yes, go ahead with the RFC! I'll try to field any questions on the mailing list as well.

I'm afraid I just hack together the graphics in Inkscape. That gives me the freedom to draw whatever is needed. I do use the colours and icons from Carto to make them feel more familiar and more clearly communicate their purpose. Glad you like them. JeroenHoek (talk) 06:12, 21 October 2020 (UTC)

After I presented our proposal here last night at an online meeting of part of our local community and received feedback and critical remarks, I have now made some additions and changes again. Especially the Rationale chapter has been updated to better explain why this tag is needed at all (not everyone was convinced). In the tagging chapter I made the two alternatives (separate vs. parking:lane scheme) more visible and also added a note about grouping with a relation.

I also got the feedback to emphasize the street_side areas on your images. I tried this on the first graphic with a new emphasized outline - if you have a better idea, you are welcome to change it again :)

Feel free to rechange everything. I will wait a day or two for more feedback and then send it to the Tagging Mailing List.--Supaplex030 (talk) 11:24, 21 October 2020 (UTC)

Sorry you had to go to the trouble to edit the PNG; it's much easier to add details to the source SVG.

Note: Do not use parking=street_side on these parking spaces if they are already part of a larger area with this tag

This may be something that needs fixing in the JOSM preset of parking_space. I usually fill it in because of the preset that offers the drop-down list. Good call on the parking site relation instead of just a plain relation for groupin, I didn't think of that. JeroenHoek (talk) 16:32, 21 October 2020 (UTC)

Again some changes after I got more feedback. Added some rendering samples now and regrouped the chapters, so "Tagging" is more visible and the layby/lay_by-Problem is a bit more highlighted.--Supaplex030 (talk) 10:09, 22 October 2020 (UTC)

Just startet RFC. For your information, there's also a discussion at GitHub that deals with this type of parking in another context: https://github.com/osm-fr/osmose-backend/issues/626#issuecomment-714745322. --Supaplex030 (talk) 11:33, 24 October 2020 (UTC)

Hey Jeroen, I have just made a few minor changes to the proposal, including rewording the proposal introduction and adding another example. What do you think - should we start a voting at the end of the week? Or would you like to change something? Do you think the font in the graphic (see below) could be a bit bigger?--Supaplex030 (talk) 20:57, 10 November 2020 (UTC)

Hi! Yes, I think we should be ready for voting by the weekend. I'll have a look at your changes tomorrow. JeroenHoek (talk) 08:02, 12 November 2020 (UTC)

I think it's looking good. JeroenHoek (talk) 08:33, 14 November 2020 (UTC)

Nice, then I'll write a voting invitation today or tomorrow! --Supaplex030 (talk) 09:39, 14 November 2020 (UTC)

street-side parking graphics

Hey, saw your change to the graphics - but the criticism was more about the visibility of the individual parking_spaces. The first impression could be that these are meant by/part of the proposal. Hence the idea that the individual parking_spaces should either not be visible anymore (or only very slightly, dashed), but rather only the bay as a whole. Or, alternatively, that the bay as a whole is clearly highlighted... Because the bay object is the focus of our proposal. Do you understand what I mean and change it again?--Supaplex030 (talk) 16:23, 21 October 2020 (UTC)

Hang on, I'll make the lines more transparent. JeroenHoek (talk) 16:32, 21 October 2020 (UTC)

Yes, I think, now it is visible enough :-p --Supaplex030 (talk) 16:44, 21 October 2020 (UTC)

Could you make the text on this graphic a bit bigger? It is difficult to read even at full resolution. Maybe the text for small areas next to them and draw a small line to the area? Thanks for your nice graphics! --Supaplex030 (talk) 18:25, 26 October 2020 (UTC)

parking=street_side

First of all, thank you for creating this proposal! I see you have edited the Key:parking page to accomodate for the new value. But why is still layby, lane etc documented? I thought part of the proposal was to deprecate those? --Westnordost (talk) 18:48, 4 December 2020 (UTC)

Hello, I see our messages have crossed. I have addressed this here https://github.com/westnordost/StreetComplete/issues/2346 . — JeroenHoek (talk) 18:57, 4 December 2020 (UTC)

context

"Please don't make unsubstantiated claims: https://www.quora.com/Is-the-word-tinker-offensive Context matters!" on https://wiki.openstreetmap.org/w/index.php?title=Tag:residential%3Dhalting_site&diff=2182301&oldid=2182234

Note that page you linked describes this term as offensive/derogatory when used to describe an ethic group. Mateusz Konieczny (talk) 17:37, 2 August 2021 (UTC)

Only when used in a derogatory manner as far as I can tell. The problem with this particular ethnic/cultural group is not that the words used for them are slurs or offensive terms as such, it is that in a lot of places they simply have a bad reputation. This answer from that thread gives some typical context. The man could have called them Travellers, gypsies, tinkers, or even one of the actual slurs: it wouldn't have changed the xenophobic reaction described there one bit. Even in the Netherlands where most people who belong to this group are not ethnic Roma but indigenous descendants of farm labourers and cotters and such the same prejudices exist. You can use the Dutch word for Traveller (reiziger) and get quite judgemental reactions from people. --JeroenHoek (talk) 18:13, 2 August 2021 (UTC)

"Only when used in a derogatory manner as far as I can tell" it is likely (I am unfamiliar with this specific situation) but it was not supported at all by link used in edit description, that seemed to be intended as supporting it Mateusz Konieczny (talk) 20:38, 2 August 2021 (UTC)

The first answer explains about context here:

Because such tradesmen were often itinerant, though, and because many of them were Romani, Irish or Highland Travellers, the word became almost a synonym for ‘gypsy.’ When a naughty child draws an exasperated cry of ‘Oh, you little tinker!’ from its parents, that’s the meaning in play. And that might well be considered offensive, because it makes that heritage synonymous with bad conduct.

So if you tell a child that they are acting like a gypsy (or tinker), then that is an offensive use of those words, because you specifically invoke a negative association. On OSM we are (hopefully) only referring to the itinerant ethnic/cultural group. Because they are known under many names varying from country to country, it helps to include synonyms for the search engine to use. --JeroenHoek (talk) 06:30, 3 August 2021 (UTC)

charge

Hi, you changed litres to litre in the wiki entry https://wiki.openstreetmap.org/w/index.php?title=Key:charge&oldid=2188254. The plural of litre is litres? For example 1 litre and 100 litres? I think we should use the plural, or am I wrong here. --Surveyor54 (talk) 13:17, 18 August 2021 (UTC)

Hi, that is correct. For units like metre and litre it is customary not to write the plural because they are not integer values (you can have 0.5 litre or 3.25 metre). For other units like 'person', 'hour' and 'minute' the plural is more common though, so it's not a very strong rule. I looked at the use in TagInfo yesterday, and it seems that litre was preferred there as well. --JeroenHoek (talk) 14:09, 18 August 2021 (UTC)

Thanks for the explanation, sounds plausible.--Surveyor54 (talk) 17:48, 18 August 2021 (UTC)

You're welcome. --JeroenHoek (talk) 18:29, 18 August 2021 (UTC)

Images

Hello! And thanks for your upload - but some extra info is necessary.

Are you author of images https://wiki.openstreetmap.org/wiki/File:Fence_crossing_a_highway.jpg https://wiki.openstreetmap.org/wiki/File:Shrubbery_with_trees..jpg ?

Or is it copied from some other place (which one?)?

Would you agree to open licensing of this image, allowing its use by anyone (similarly to your OSM edits)?

Would you be OK with https://wiki.openstreetmap.org/wiki/Template:CC0 (it allows use without attribution or any other requirement) ?

Or do you prefer to require attribution and some other things using https://wiki.openstreetmap.org/wiki/Template:CC-BY-SA-4.0 ?

Mateusz Konieczny (talk) 11:14, 3 October 2021 (UTC)

The first one (fence crossing a highway) was taken by a fellow mapper. They posted it on the Dutch OSM forum to illustrate a tagging issue, and I approached them for permission to reuse it here, which they granted. So that would probably be CC-BY-SA attributed to Jo'el Richters.

The other one (shrubbery) was taken by me. By all means, mark that as public domain. --JeroenHoek (talk) 11:20, 3 October 2021 (UTC)

Missing file information

Hello! And thanks for your upload - but some extra info is necessary.

Sorry for bothering you about this, but it is important to know source of the uploaded files.

Are you the author of image File:Aeroway-markings.png ?

Or is it copied from some other place (which one?)?

Please, add this info to the file page - something like "I took this photo" or "downloaded from -website link-" or "I took this screeshot of program XYZ".

In case that you are the author of the image: Would you agree to open licensing of this image, allowing its use by anyone (similarly to your OSM edits)?

Would you be OK with CC0 (it allows use without attribution or any other requirement)?

Or do you prefer to require attribution and some other things using CC-BY-SA-4.0?

If you are the author: Please add {{CC0-self}} to the file page to publish the image under CC0 license.

You can also use {{CC-BY-SA-4.0-self}} to publish under CC-BY-SA-4.0 license.

Note that in cases where photo is a screenshot of some software interface: usually it is needed to handle also copyright of software itself.

Note that in cases where aerial imagery is present: also licensing of an aerial imagery matter.

Feel free to ask for help if you need it - you can do it for example by asking on Talk:Wiki: new topic.

Please ask there if you are not sure what is the proper next step. Especially when you are uploading files that are not your own work or are derivative work (screenshots, composition of images, using aerial imagery etc).

Once you add missing data - please remove {{Unknown|subcategory=uploader notified January 2022}} from the file page.

--Mateusz Konieczny (talk) 10:34, 26 January 2022 (UTC)

I explicitly checked the checkbox that states This is my own work when I uploaded this, so of course it is my own work. The file upload dialog currently doesn't give the user any indication any other action (like selecting a license) is needed. You may want to get that fixed first to prevent having to ask this question to every wiki contributor for future uploads. --JeroenHoek (talk) 10:44, 26 January 2022 (UTC)

Thanks, I will definitely look into this Mateusz Konieczny (talk) 11:23, 26 January 2022 (UTC)

IT was improved, at least partially. See https://wiki.openstreetmap.org/wiki/Talk:Wiki#Special:Upload_suggested_licenses:_add_-self_templates_in_the_list Mateusz Konieczny (talk) 18:57, 16 June 2022 (UTC)

Thanks for looking into that. I am seeing a dropdown list in Special:Upload, but nothing seems to have changed in the inline upload dialog. I don't know how other users use them, but I've never used Special:Upload. I always upload the pictures I need while editing an article or reply. Can that dropdown list be added there? --JeroenHoek (talk) 07:19, 26 June 2022 (UTC)

Is it covered by https://wiki.openstreetmap.org/wiki/Talk:Wiki#File_upload_in_VisualEditor_lacks_information_of_copyright_or_license ? In general I would consider uploading to https://commons.wikimedia.org/ except completely throwaway images (we can try to maintain some bare minimum, but Wikimedia Commons focuses specifically on images and any images uploaded there can be used directly at OSM Wiki) Mateusz Konieczny (talk) 11:43, 26 June 2022 (UTC)

Yes, that is the same issue. I use Wikimedia Commons for images that are of general interest, like this CC0 aerial photograph, but there is lots of stuff that only makes sense here, and where updates to that file should be done here too and not conflict with other consumers of Wikimedia Commons, like this schematic. Those would belong here on the wiki right? --JeroenHoek (talk) 12:27, 26 June 2022 (UTC)

Things like File:Parking-street-side.png can be uploaded to Wikimedia Commons. For start, "can be used to write book about OSM" (maybe at https://en.wikibooks.org/wiki/Main_Page ) already passes scope requirement. Also, it could be used to illustrate topics about maps, urban design etc. It is fully in scope. Only things like "here is an image of buggy display of OSM Wiki page" may not qualify (and even that can be argued as potentially usable for book about software bugs). Mateusz Konieczny (talk) 12:58, 26 June 2022 (UTC)

sheela-na-gig table captions

Am I allowed to change them while the vote is on or do I have to wait? I honestly didn't notice it before. B-unicycling (talk) 20:28, 22 March 2022 (UTC)

Minor things like grammar and clarifications are OK in general, as long as you don't change the intent of the page. I expect that you didn't intend to make subject:wikipedia=Q509424 mandatory. I would recommend changing the two 'Caption text's over those two tables to 'required' and 'optional'. --JeroenHoek (talk) 21:08, 22 March 2022 (UTC)

Missing file information

Hello! And thanks for your upload - but some extra info is necessary.

Sorry for bothering you about this, but it is important to know source of the uploaded files.

Are you the creator of image File:Footway-link-example.png ?

Or is it copied from some other place (which one?)?

Please, add this info to the file page - something like "I took this photo" or "downloaded from -website link-" or "I took this screeshot of program XYZ" or "this is map generated from OpenStreetMap data and SRTM data" or "map generated from OSM data and only OSM data" or "This is my work based on file -link-to-page-with-that-file-and-its-licensing-info-" or "used file downloaded from internet to create it, no idea which one".

Doing this would be already very useful.

Licensing - photos

In case that you are the author of the image: Would you agree to open licensing of this image, allowing its use by anyone (similarly to your OSM edits)?

In case where it is a photo you (except relatively rare cases) author can make it available under a specific free license.

Would you be OK with CC0 (it allows use without attribution or any other requirement)?

Or do you prefer to require attribution and some other things using CC-BY-SA-4.0?

If you are the author: Please add {{CC0-self}} to the file page to publish the image under CC0 license.

You can also use {{CC-BY-SA-4.0-self|JeroenHoek}} to publish under CC-BY-SA-4.0 license.

Once you add missing data - please remove {{Unknown|subcategory=uploader notified 2022, May}} from the file page.

Licensing - other images

If it is not a photo situation gets a bit more complicated.

See Drafts/Media file license chart that may help.

note: if you took screenshot of program made by someone else, screenshot of OSM editor with aerial imagery: then licensing of that elements also matter and you are not a sole author.

note: If you downloaded image made by someone else then you are NOT the author.

Note that in cases where photo is a screenshot of some software interface: usually it is needed to handle also copyright of software itself.

Note that in cases where aerial imagery is present: also licensing of an aerial imagery matter.

Help

Feel free to ask for help if you need it - you can do it for example by asking on Talk:Wiki: new topic.

Please ask there if you are not sure what is the proper next step. Especially when you are uploading files that are not your own work or are derivative work (screenshots, composition of images, using aerial imagery etc).

If you are interested in wider discussion about handling licencing at OSM Wiki, see this thread.

(sorry if I missed something that already states license and source: I am looking through over 20 000 files and fixing obvious cases on my own, in other I ask people who upladed files, but it is possible that I missed something - in such case also please answer)

--Mateusz Konieczny (talk) 22:44, 2 May 2022 (UTC)

@Mateusz Konieczny: Please ask Voiden; I uploaded it at their request because they lacked file upload rights as a new user. See this talk page. --JeroenHoek (talk) 13:53, 11 May 2022 (UTC)

Thanks, done Mateusz Konieczny (talk) 14:07, 11 May 2022 (UTC)

Attribution

Hello! And sorry for bothering you, but description of file you uploaded need to be improved.

You have uploaded file which is licensed as requiring attribution. But right now attribution is not specified properly.

Please, ask for help if something is confusing or unclear in this message.

Please, fix that problem with this uploads - note that images with unclear licensing situation may be deleted.

Attribution may be missing completely or just be specified in nonstandard way, in either case it needs to be improved. Note that using CC-BY files without specifying attribution is a copyright violation, which is often unethical and unwanted. So clearly specifying required attribution is needed if license which makes attribution mandatory was used.

If it is applying to your own work which not based on work by others - then you can select own user name or some other preferred attribution or even change license to for example {{CC0-self}}

For your own work: ensure that it is clearly stated at file page that you created image/took the photo/etc

For works by others - please ensure that there is link to the original source which confirms license and that you used proper attribution, or that source is clearly stated in some other way.

Especially for old OSM-baded maps, made from data before license change on 12 September 2012 you should use "map data © OpenStreetMap contributors" as at least part of attribution

For old OSM Carto maps, which predate license change on 12 September 2012 you can use a special template {{OSM Carto screenshot||old_license}}

Note: Maybe the current license on this file is wrong and a different one should be used! Wiki:Media file license chart may be helpful. If unsure, ask on Talk:Wiki

• File:Example of aeroway markings.png

Aeroways: displaced_threshold tagging

Jeroen,

Excuse me for being quite unhappy with your recent reversal of my edit, cfr. [url]https://wiki.openstreetmap.org/w/index.php?title=Proposed_features%2Frunway%3Ddisplaced_threshold&type=revision&diff=2483095&oldid=2482595[/url]

After you have ignored my repeated requests for discussion, you now simply insist on having things "your own way", to make the definition suit your very own personal preference. Even if I do not like to play the school teacher, or the master of morals, allow me to remind you that OSM is not anybody's personal playground.

I will not enter revert wars, therefore please undo your reversal reversal, for the sake of good manners and collaboration. As long as the dispute is not settled, I wish for the alternate way of mapping a displaced threshold, i.e. as a mark on the runway, and nothing more, to be mentioned in the wiki, and will proceed to do so, unless you offer convincing arguments on the short term.

Thanks in advance, Jan olieslagers (talk) 17:00, 26 February 2023 (UTC)

Joh, lees even goed dat voorstel door en kijk ook even naar het daadwerkelijke gebruik van de tag inmiddels. De tag is namelijk al ruim in gebruik, en de opsteller heeft heel bewust die definitie gekozen met voorbeeldafbeeldingen en alles er bij. Wat je deed in je bewerking was niet een kleine tekstuele wijziging, maar een fundamentele wijziging van de tag: „A displaced threshold is a runway threshold located at a point other than the physical beginning or end of the runway”. Daarmee wek je de indruk dat deze tag op een node toegepast moet worden exact op het punt van de displaced threshold. Dat is niet hoe de tag nu al 1000 keer gebruikt is. Deze wijziging kun je niet zomaar doorvoeren op dit punt; het is geen kersvers voorstel, maar één die (te lang) is blijven steken in deze fase, maar al wel wordt toegepast.

Ik snap je irritatie over de semantiek van de tagnaam, maar als je deze beschouwt als „Het stuk baan van rand tot de displaced threshold lijn”, dan klopt het. Niemand betwist dat de displaced threshold strikt genomen die lijn is op de grens van de twee stukken baan, maar dat betekent niet dat deze tag ook zo toegepast moet worden. Het brengt namelijk ook een aantal nadelen met zich mee.

Had je eigenlijk wel gezien dat er al 1000 stukken startbaan zo getagt waren als lijn? Door hem ook als punt-tag te documenteren kaap je een bestaand voorstel dat al breed toegepast wordt. Dat is ook de reden dat ik je bewerking niet heb laten staan: om te voorkomen dat mappers hem plotseling zo gaan toepassen op node, terwijl dit voorstel daar bewust niet in voorziet. --JeroenHoek (talk) 17:56, 26 February 2023 (UTC)

Thanks for quick reply. It is however not because a thousand incorrect edits have been made on the basis of an incorrect wiki entry that the incorrect entry becomes correct. The more so that the incorrect wiki entry has never been confirmed by any vote or other means of consensus. Again, at the very minimum least you should accept that mapping a displaced threshold as a node is also acceptable. Jan olieslagers (talk) 18:06, 26 February 2023 (UTC)

Met 1000 tags (minstens 500 banen dus), spreek je niet meer over een ideetje, maar over een in-gebruik-zijnde tag. En ja, die is dus veel te langs als proposal blijven liggen, maar geef de opsteller eens ongelijk als je de gemiddelde tag-discussie ziet. Maar wat is er nou niet juist? Je kan deze semantische discussie toch oplossen door te documenteren dat de daadwerkelijke threshold de lijn is waar deze way eindigt en overgaat in de 'normale' baan? Door hem als node te taggen gooi je informatie weg over welk deel van de baan dus alleen voor starten bedoeld is. Renderers kunnen daar gebruik van maken (zie voorbeeld op de talk-page), en data-consumers kunnen daarmee aan de slag (baanlengtes etc.).

Een stukje documentatie die dit onderscheid duidelijk maakt is een stuk effectiever dan per se een variant te willen introduceren die niet in gebruik is en botst met de bestaande manier.

Waar zit precies je angst en bezwaar? Deze manier van taggen tagt correct een stuk baan als zijnde enkel voor opstijgen. De zo getagde way komt ook exact overeen met het stuk baan wat met die pijlen gemarkeerd is. De mappers die hem nu als way taggen zullen niet massaal overstappen op de node-manier, dus het enige wat je creëert is tweespalt. Zit het hem voor jou dan enkel in de naam van de tag? --JeroenHoek (talk) 18:18, 26 February 2023 (UTC)

Do we map trees as flowers? Do we map rivers as railways? Why should we mark a certain point on a runway as anything else? Yes I strongly insist on correct semantics. On mapping a bench in the park as a bench in the park, and a biscuit shop as a biscuit shop.

What renderers do with it is irrelevant anyway. Ever heard say "do not map for the renderer"? And a somewhat intelligent renderer can handle a correctly mapped displaced threshold just as well, that's not rocket science, neither black magic.

Most of all however I question and reject your questionable tactics. You are defending an incorrect way of tagging on grounds that are highly arguable, you have never taken the proposal to the voting stage, you just want to have things to be your way. It comes across very much like "I and only I know how it should be" and that goes down badly with me, because it is contrary to the very basic spirit of OSM. OSM has always been open to multiple ways of mapping. I insist that you should accept the mapping of displaced thresholds as a node - which is after all what they are, even you cannot deny that. Should we really map trees as flowers? Railways as lakes? At least people should be offered the option of mapping a railway station as a railway station.

And by the way, the one bit of information that could and would really make sense to me is to add the official data from the AIP to the relevant runways: length, width, TORA, LDA, &c.

You might also ponder this, from en:wikipedia: [quote]The runway is the surface from threshold to threshold (including displaced thresholds), which typically features threshold markings, numbers, and centerlines, but excludes blast pads and stopways at both ends.[/quote] Jan olieslagers (talk) 18:35, 26 February 2023 (UTC)

Dus in plaats daarvan ga je een tag-definitie die door meerdere mappers gebruikt wordt aanpassen met een variant (die de huidige manier niet vervangt, maar aanvult)? Dat is niet bepaald beleefd. Maar wat is nou het probleem met de definitie toelichten op deze wijze: „runway=displaced threshold: the part of the runway used exclusively for take-off leading up to the displaced threshold line.” Dat is de weg van de minste weerstand, en doet recht aan het voorstel zoals die nu gebruikt wordt. Dus: lees runway=displaced_theshold als een handzame afkorting voor runway=from_edge_to_displaced_threshold en het klopt.

If you wish to tag "runway=from_edge_to_displaced_threshold": I see little added value in it, but I cannot and won't stop you from using that tag. But call it what it is: nylon socks are nylon socks, not pantyhose.

Het alternatief is dat je twee manieren van tagging hebt. Ga je ze allemaal omtaggen naar de node vorm? Krijg je alle mappers die hier aan bijgedragen hebben daarin mee? Anders houdt je permanent twee manieren van taggen voor een niche-onderwerp. Dat lijkt mij een slechtere uitkomst dan gewoon de documentatie verbeteren qua uitleg en de huidige methodiek handhaven.

There are plenty of things than can be mapped in several ways. And no I would not retag the existant, or urge people to do so. Leave options open, offer choices to mappers. As things stand now, the wiki discourages mapping an elephant cage as an elephant cage. For the umpteenth time: at least the option should be mentioned. Jan olieslagers (talk) 19:35, 26 February 2023 (UTC)

(Overigens, wij spreken toch beiden gewoon Nederlands?) --JeroenHoek (talk) 19:25, 26 February 2023 (UTC)

That point is much appreciated, and answered with a broad smile: I usually insist upon using our own Dutch language wherever I come. However this whole wiki being in Shakespeare's language - of which you appear to have excellent mastery! - I thought it best to stick to that. The more so that @Claudius/@Grille_Chompa might not master our language as well, and he might well be interested to follow. Jan olieslagers (talk) 19:35, 26 February 2023 (UTC)

Long Texts

You took the easy way out and hit the revert button instead of looking at what I've done. I'm trying to shorten and simplify a text. People don't like to read long, complicated texts. Regarding your Oxford comma, the text now contains multiple sentences like thisː "Jan, and Truus go to school". Please explain to me if this is good use of that comma.--Kogacarlo (talk) 12:44, 9 October 2023 (UTC)

Ik heb de diff uitgebreid bekeken, maar er zat niets in wat fout was in mijn tekst. Alleen deze komma hoort er inderdaad niet in thuis:

[…] between the rear sides of buildings such as houses, and commercial premises […]

Verbeteren is prima, maar alleen maar schuiven van Brits Engels naar Amerikaans Engels is niet correct op deze wiki (ook door de historische aanwezigheid van Britse terminologie in OSM). --JeroenHoek (talk) 12:54, 9 October 2023 (UTC)

amenity=emergency_service and emergency=disaster_response

Hi JeroenHoek, I just rechanged a note you changed, see here. emergency=disaster_response is not a perfect replacement for the deprecated tag. There are some facilitys of the German THW that use the old tag(s) but do not fit the new one, see here. --Os-emmer (talk) 12:42, 28 January 2024 (UTC)