That was to be expected. You should expect the possibility that this could happen at any time to any other AWS hosted open data sets from https://registry.opendata.aws/

Anyway your assessment that the Copernicus Open Access Hub is the only way to access the data is wrong - there are plenty of other options meanwhile. Note however if you want a recent image the Open Access Hub will always be the fastest.

You can find a fairly extensive list of alternative access methods on

https://github.com/Fernerkundung/awesome-sentinel

while it can argued that having a non-github like issue tracker would remove the real or imagined bias towards software developers, it is however unlikely that the devs would want to give up the tight integration of the issue tracker with git that github-like systems provide.

Which is why i specifically focused on projects that are not primarily software development projects - just look at the examples i gave.

Should we in the future at some point have such a system established it seems pretty likely to me that software developers would deliberately use it for purposes where they seek input from the broader OSM community and not just developers.

And i think even having one of the various open source github clones set up specifically for OSM use (with as you said single sign on) could already - through a different culture of use and nuances in configuration - be significantly more non-developer friendly.

Right - i tried to make it a bit simpler than it actually is.

Self intersecting closed ways will also not show up in the map any more.

And open ring errors of course do not happen with closed ways. ;-)

That’s a broken multipolygon:

http://tools.geofabrik.de/osmi/?view=areas&lon=12.92661&lat=57.46135&zoom=10

And yes, splitting this into smaller and less complex polygons is a good idea.

A summary or paraphrasing of communication is always subjective. Just to give you an example: In the original ideas there was

• We should stop (to) look at OSM as a tech project.

You write:

• We should stop to consider the essence of OSM as a technological project.

I do not necessarily disagree with the interpretation but this is definitely not semantically the same statement. If i had written that i would probably like to have it reproduced accurately and any subjective interpretation being indicated as such.

There are also statements i do not find covered in your summary - most obvious the somewhat ambiguous “stop the insulting men”. I don’t want to try giving a full list of ideas you missed because that would be my subjective interpretation of the ideas.

Thanks for the summary of that session.

I am somewhat irritated by the list of ideas presented here and how it differs from what can be found in:

https://pads.ccc.de/WXSlyAqS8t

Presenting a subjective selection of the ideas communicated or paraphrasing them IMO kind of defeats the idea of the whole exercise to collect diverse ideas and to let people express themselves how they feel about things directly. I think it is also a matter of fairness towards those who wrote their ideas on a sticker there to faithfully reproduce what they wrote and not just engross their contribution in a selective summary.

The exact titles of the sections by the way - as visible in the photos - were:

• I will do
• We should stop
• We should start or continue

I know many non-programmer mappers who dislike being forced or urged to use github to participate in OSM related discussions. This might not always have identifiable reasons in usability - it might in parts simply be a psychological effect of visiting a place that is obviously primarily meant and optimized for programmers.

The way github presents and scores the users for example (with contributor activity information, repositories etc.) is clearly favoring developers. Objectively this is not all that meaningful but it still communicates certain priorities and preferences to people.

In your sample rendering the drawing order of the roads looks odd, kind of random.

Regarding styling, i have to say at the moment i don’t really see where it aims at. It to me pretty much looks like an OpenMapTiles/MapboxStreets look-alike in slightly different colors but without a distinct cartographic direction. I know this is still in an early state but i would contemplate the question of cartographic goals before putting too much work into it. Starting with a clear vision design wise can help you a lot.

Thanks for sharing your observations.

I would advise a bit of caution with the emphasis on how many different countries the participants came from. This is a relatively poor measure of the geographic diversity at the conference. It is a bit like claiming to have gender diversity because you also have a woman in your group.

2/3 of the visitors at the conference were from Western Europe or the United States, the vast majority of them from Italy, Germany, US, UK, France and Switzerland. About half of the 56 countries were only present with one person and about half of those were there through some kind of scholarship.

This is all fairly natural for a conference like this and from my point of views is no indication for a particular degree of geographic and cultural inclusiveness or of being representative for the OSM community (see here for some numbers regarding the geographic distribution of mappers).

BTW, @SK53 - we missed you in Milano.

Nice.

It is somewhat unfortunate that you recorded it on Sunday so you could not take the Monday talks into account.

Regarding vector tiles - the problem of minutely updates of vector tiles without a PostGIS database is something that was a topic in the discussion after Thomas Skowron’s talk on the first day. This is an interesting topic. But most toolchains at the moment are based on a PostGIS database anyway.

The idea of a layer-less rendering framework (which you seem to hint at in the discussion) is something i have contemplated as well. But this would be really hard to get people to warm up to since this is so firmly embedded into cartography and graphics design in general (and in fact clearly predates the digital age).

Ah, that makes much more sense now.

What i find fascinating is that you seem to treat the image tiles completely independently - in other words: cut off building parts at a tile edge are treated as if they were whole buildings.

I can see that this affects the algorithm because we see the discontinuities in the results but I wonder how ‘local’ the method is ultimately when you apply the trained algorithm. I mean if you move the tile edge a tiny bit (a few pixel) would the results change completely across the whole tile potentially or would such a move only affect the results near the edge of the tile and leave the rest unaffected?

Interesting results.

My gut feeling after reading is that the reason for the quite significant difference between men and women observed regarding types of features mapped could very well be partly due to men and women in the survey participating differently in organized mapping efforts. Most organized mapping focuses on certain types of features which could explain to some extent the differences in tag use observed if it plays a different role in the mapping of men and women analyzed.

The thing with organized mapping is that since this is usually not fully self determined (there are usually some kind of instructions on what to map with preference) this can kind of distort the attempt to find out what mapping preferences men and women typically have.

Likewise different preferences regarding outdoor mapping vs. armchair mapping could also result in different thematic mapping patterns.

But of course if women participate more frequently in organized mapping (or participate in different kinds of organized mapping efforts) or if they have a higher or lower preference for armchair mapping this would be a valuable observation on its own.

@SimonPoole - you want to finance that?

The main problems of this idea are in parts already demonstrated by Landsat Live from Mapbox:

• If you just blindly show the latest image everywhere you have something of rather limited use for mapping because of clouds and other reasons why the newest image is not the best. If you want to hand select the best image from some kind of recent time frame for every area we are talking about a quite a lot of work on a regular basis that requires significant qualification to be performed well.
• If you use a dumb, constant color processing you get results of very limited usefulness in many areas - see here for some details on this.
• If you offer all individual images separately image selection is a task of significant difficulty for the mapper, in particular in high cloud incidence areas.

There are already services that offer online access to the standard ESA TCI rendering of some Sentinel-2 images. For the shown image you can for example use (in JOSM notation):

https://geoservice.code-de.org/Sentinel2/wms?SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&FORMAT=image%2Fpng&TRANSPARENT=true&LAYERS=S2_MSI_L1C&time=2018-06-09T07%3A56%3A11.024Z%2F2018-06-09T07%3A56%3A11.024Z&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}

Note this WMS is currently not advertised for arbitrary use AFAIK so it is not clear if they are fine with using it for mapping. If you intend to use this you should probably contact code-de (contact details in the GetCapabilities or on the website).

Thanks for the reply to my comments. My main point about the methodology was that i for example have difficulties interpreting the 33% of women have felt hostility from men in their community. Quantitative observations like this require context to be quantitatively meaningful. Without context i can only see that there is a significant fraction of women who have participated in the survey who have experienced hostility. And frankly this is something i would expect since occurrence of hostility in social interaction is in my experience something universal and the question was for any occurrence of any kind of hostility. If i assume most of the women in the survey have been in the OSM community for at least a few years (which i am not sure i can) i would in fact expect the number to be higher. Frequent interaction with a large community with a larger number of people for a year or longer without any incident of hostility seems - as desirable as it might be - unusual to me. And in the other numbers i can see there is a significant difference between self-perception of hostility towards oneself and perception of hostility towards others which is - when considered purely qualitatively - also an expected observation, even without any gender difference.

Regarding the impression that many consider gender inequality in the community to be no problem - without examples it is difficult to specifically analyze that. My own impression when talking to people (obviously mostly men) in the community is that many consider it highly desirable for there to be more women mappers, developers etc. and listen very carefully and with interest and compassion whenever they hear from women in the community about their experiences. Both lack of awareness and indifference towards the existence of gender inbalance and gender discrimination are things i see rarely in OSM, especially if i compare it to other diversity subjects (in particular social, cultural, language and geographic diversity). If and what kind of active measures are advisable to address this is a whole different story of course. Here you have in OSM a widespread view (which is also in the OSMF mission) that growth of the community of any kind should be organic and it is not a good idea to actively bootstrap community where none exists yet. This is a widespread view among people in the OSM community but this is not the same as being unaware of or indifferent towards gender inbalance.

I think this is probably also a subject where there are significant fundamental communication problems (it is difficult to articulate opinions on a highly perception dependent topic like this, especially when you do so in a non-native language) and it is easy to misinterpret statements and reactions in a way that is different from how they are meant.

Note the Here roads are largely crap. You can see that when you compare to the image layer - roads frequently cross through houses, the typical AI nonsense that allows them to advertise to their customers: We have X kilometers of roads in Iraq - more than any other map service. We will likely see a lot more like this in the future in various places but this is not a role model for OSM!

See:

https://mc.bbbike.org/mc/?lon=42.681952&lat=37.175496&zoom=17&num=4&mt0=nokia-map&mt1=mapnik&mt2=nokia-satellite&mt3=bing-satellite&marker=

For reference - here a recent (June 2018) open data image from the same area:

You have correctly pointed out that those who participated in your survey are not representative for the OSM community but i am somewhat astonished about your comment regarding the nature of the selectivity. Could you point us to some examples where people have voiced in forums/lists the opinion that “gender inequality in the community is not a problem”? I understand this kind of depends on your definition of “gender inequality” and “problem” but my impression is that it is at least very rare that people think it would not be good if there were more women among mappers than there are at the moment. I do not remember any case where on forums or mailing lists such an opinion was voiced, especially no case where this was not quickly met with strong disagreement.

A more methodological comment - like often with surveys you probably have the problem of separating indirect influences from what you actually want to find out (i.e. the differences between men and women how they experience certain things). It is for example not unlikely that the women and men who participated in your survey are on average of different age, different socio-economic background or have a different level of experience with OSM. If such differences are large they could significantly affect the results in ways that are unrelated to what you actually want to determine (the differences between men and women). Have you included questions in your survey that allow assessment of such indirect influences?

In case of the hostility related questions i am missing the symmetric counterparts of the questions you listed results for. In particular the percentage of men who have felt hostility from other men in their community. That would provide important reference points to the numbers you give.

The apparent higher ‘sensitivity’ of men to the unbalanced gender representation is an interesting observation but could be due to the indirect influences i mentioned above.

Glad to see you are following the first of my list of suggestions here - i hope you will also work on the other points.

I am also glad to read that you consider the main application of this not to be generating geometries for mapping (for which the examples you showed also quite clearly would not be the most suitable use cases). So i would scratch the “polygon recommendations for them” part of your scenarios. In particular for buildings this will likely fail miserably when done based on AI methods alone in many cases - in particular when you train not for exactly the same image (same viewing angle and same sun position) as you run it on. And in practical mapping fixing a bad geometry is often more time consuming than drawing a correct one from scratch.

I also have my doubts that post-mapping QA and remote sensing data assessment use cases as you described can much profit from this kind of method because you might end up with mostly evaluating your algorithm and its shortcomings rather than the data you want to evaluate. But this will remain to be seen.

What i can imagine to be a suitable application is some needle-in-a-haystack problems we have in mapping. Like: We have a city with 250 amenity=parking mapped - find the five ones that are missing and the five other ones that have significantly changed in size. This is a type of problem that will become increasingly important as OSM matures and reaches a high level of completeness in some aspects.

Coastline editing is actually not that difficult, especially if you only move and add nodes. What can be irritating is that you do not get an immediate update in the map (and in the past two months the coastline updates were completely stuck).

So the main rules for coastline editing are: Don’t break it and ignore how it looks on the map. Useful visual feedback you can get from the OSM Inspector water view (with 1-2 days delay):

http://tools.geofabrik.de/osmi/?view=water&lon=53.37586&lat=39.82378&zoom=10