User talk:Imagico

Glaciers tags

Hi Imagico, I've been updating the Glaciers tags proposal with the most recent developments from the discussion, and I would like to know your opinion about it. I'll also add the clever type classification scheme you proposed, as soon as it goes from draft to final. Besides, I added a couple of ideas concerning the last three topics of the discussion and I would like to discuss them with you, if you were to take a look.

Thanks

Ocirne

Moraine/scree/debris cover for glaciers

Hi Imagico,

on the topic "debris cover on top of a glacier" I've been pondering the various options, and I've come to some conclusions about the pros and cons. I would like your opinion on it, in order to complete this hopefully last step of the glaciers tags proposal; please find the table on the proposal's talk page. Also, can I post your type classification scheme to the proposal page, with the addition of the "remnant" type?

Thanks, Ocirne94 (talk) 15:39, 21 February 2013 (UTC)

Feel free to use the classification scheme --Imagico (talk) 23:45, 21 February 2013 (UTC)

Thank you; I've also added a small note concerning the use of glacier:type=snow. Ocirne94 (talk) 16:23, 22 February 2013 (UTC)

Re: Glacier proposal

Hi Imagico, unfortunately I've been very busy at university so I wasn't able to make any changes to the proposal. Of course I'm still interested, and I followed (not continously though) your import of the ADD. I really like the scheme you used for moraines.

I will now edit the proposal's page accordingly; in general, if you have more time than I have, please feel free to edit the proposal's page any time you want. Ocirne94 (talk) 18:10, 11 November 2013 (UTC)

Thanks - i do not have much to change but i thought it would be prudent to keep this up-to-date. --Imagico (talk) 18:52, 11 November 2013 (UTC)

P.S.: concerning snow, wouldn't "natural=snowfield" be more consistent? "natural=snow" would be consistent with "natural=ice", not with "natural=glacier". On taginfo I see that snow is used 5 times, snowfield 8. What do you think?

Yes, probably better. The mapping of snow will always be problematic since the extent of a permanent snow field is usually much more variable than that of a glacier. --Imagico (talk) 18:52, 11 November 2013 (UTC)

One more glaciers tag

Ok, I've moved everything to the proposal's talk page. Ocirne94 (talk) 14:02, 1 February 2014 (UTC)

Re: Glacier proposal

Hi Imagico, I've seen the changes but I haven't had time yet to give them a thorough read. I'll do it asap. Ocirne94 (talk) 14:19, 18 February 2014 (UTC)

Election questions intro

I hope you don't mind, I re-arranged this page a bit to make the questions look consistent: Talk:Foundation/AGM15/Election_to_Board. I liked the introduction to your questions, so I moved that up to be the introduction to all the questions! -- Harry Wood (talk) 18:35, 19 November 2015 (UTC)

That's fine, thanks.--Imagico (talk) 18:52, 19 November 2015 (UTC)

automated edit box

Sophox tool is neither an import tool nor an automated tool according to Automated Edits code of conduct and Automated edits. I understand you might not like the tool, but unless you want to add the same warning to MapRoulette, Osmose, JOSM and many other, lets not dilute the meaning of the infobox. --Yurik (talk) 22:32, 14 November 2017 (UTC)

Thanks for explaining why you added it to Sophox. The automated feature has not been implemented, and I doubt it will be any time soon. See info box at the bottom. [1]. I have removed the whole mentioning of the automation to avoid any confusion. --Yurik (talk) 23:11, 14 November 2017 (UTC)

Key:place

Thank you. I realize I by mistake tried to change an old version of this page.

Glad this was just a mistake. Please do feel encouraged to improve the documentation where it is lacking.--Imagico (talk) 20:15, 13 April 2018 (UTC)

I'll do my best :-) I certainly do see the need for better documentation in a number of areas (since I interact with a lot of less experienced mappers on a daily basis and see where they stumble) and for years I've had an increasing number of ideas on how to improve, but unfortunately tend to get caught up in ordinary mapping. Note that I see https://wiki.openstreetmap.org/wiki/Key:place#Mapping_populated_places_as_areas as quite political and am considering how to make it less so.--Hjart (talk) 21:55, 13 April 2018 (UTC)

Actually that section is probably the most matter-of-factually part of the whole page at the moment. It documents what the tags are used for which is the core of tag documentation. The bogus considerations about geocoder and router design (which are both off-topic and distorting) are a different story.

The statement in most cases they have a well defined centre is anything but "matter of fact". In my experience (having mapped intensely pretty much all over the globe for many years), it's nothing but a myth. but not meant to represent a meaningful outline in my experience is a purely political statement, nothing factual about that. Same with several other points in that section.

You are welcome to argue any of the statements you consider inaccurate on the talk page. That settlements in most cases have a well defined centre is AFAIK fairly undisputed in settlement geography. There are known exceptions for this, for example settlements that developed along roads without a clear starting point or settlements that developed around several centres like several originally separate farms. But even in those cases a well defined functional center often develops over time. Explaining better how you can identify the center of a settlement in various cases is something that would deserve more elaborate explanation of course.

I also kind of doubt you can seriously question the widespread existence of settlements mapped with polygons not meant to represent a meaningful outline in the OSM database. In particular this is an almost universal part of HOT mapping instructions - to draw wrapper polygons around groups of buildings.

Please take further discussion of this to Talk:Key:place.--Imagico (talk) 09:05, 14 April 2018 (UTC)

Looking at the data (preferably world wide) is usually a good starting point for making improvements.--Imagico (talk) 22:34, 13 April 2018 (UTC)

I'll agree with that and I might actually be exactly the right person to do those improvements then: (Where Hjart mapped over the years). I've seen enough OSM place nodes etc over the years to have a pretty good idea. --Hjart (talk) 09:16, 14 April 2018 (UTC)

natural=gully

Hi, not sure if you have seen my reply/Q here RicoZ (talk) 16:51, 2 October 2018 (UTC)

Your edit on Tag:natural=beach

Hi! Has this been discussed somewhere? Most beaches are mapped above the mean high water spring line (natural=coastline). Allowing that beaches are mapped either above or across the coastline is not consistent and doesn't help map users (as they may expect a beach to be much larger than it is at high sea level). Regards –SelfishSeahorse (talk) 21:12, 26 February 2019 (UTC)

I think the description as I wrote it reflects actual mapping practice. Note the coastline does not always represent the high water line - in many cases both the coastline and the beach extent are mapped just as they appear on the image used by the mapper in question - which rarely shows a high tide situation. In cases where the coastline is accurately placed at the high water line it seems more common to map the beach across the coastline because it would otherwise usually be very narrow. I would personally prefer if beaches were consistently mapped down to the low water line but there is no agreement on this being required. --Imagico (talk) 21:34, 26 February 2019 (UTC)

In my opinion it is helpful to know the size of the part of the beach that is always there (and dry) and the size of the part that is flooded at high tide. Therefore it were better if natural=beach were restricted to the part above the high water line and if the part in the tidal range were mapped as a separate area tagged tidal=yes. –SelfishSeahorse (talk) 15:20, 2 March 2019 (UTC)

If the coastline is accurately mapped that is unnecessary work and complicates mapping without any substantial gain in information. But i don't mind if mappers do this. So far however this is not really common practice. --Imagico (talk) 15:29, 2 March 2019 (UTC)

But it would help data consumers and renderers, won't it? –SelfishSeahorse (talk) 15:43, 2 March 2019 (UTC)

Wouldn't really see how - you need the coastline anyway. --Imagico (talk) 15:49, 2 March 2019 (UTC)

For example, renderes won't have to divide the beach beforehand if they want to display the part of the beach that is flooded at high tide differently. –SelfishSeahorse (talk) 19:00, 2 March 2019 (UTC)

Practically this is not a significant issue - and even if it was it would not be a good reason to complicate mapping to cater specific limitations of certain rendering tools. --Imagico (talk) 11:55, 5 March 2019 (UTC)

ESA Landsat 8 Web Portal

You listed old at https://wiki.openstreetmap.org/wiki/Lacking_proper_attribution as lacking proper attribution. It seems to be unavailable under old address. Is a new one still violation OSM license? Mateusz Konieczny (talk) 11:40, 25 June 2023 (UTC)

I don't think there is a true successor of that page - the only thing that comes close is https://landsat-diss.eo.esa.int/socat/LANDSAT-8_L1.

More significant because much more high profile is the deliberately non-readable attribution on https://scihub.copernicus.eu/dhus/. There are also instances of the same software (like https://colhub.met.no/, https://data.sentinel.zamg.ac.at/dhus/) that use OSMF tiles with the same kind of explicit showing OSM the finger attribution.

--Imagico (talk) 12:41, 25 June 2023 (UTC)

Thanks, I updated page and wrote to them Mateusz Konieczny (talk) 14:00, 29 June 2023 (UTC)

Thanks, much appreciated. --Imagico (talk) 14:27, 29 June 2023 (UTC)

If you know about other similarly problematic cases - adding them to the page (even without writing to them) would be helpful, and sending also standard mail would be even better Mateusz Konieczny (talk) 14:41, 29 June 2023 (UTC)