Re: [osm-hu] Questionable edits around Alsószölnök

[ITineris Kft]

Hi,

Part of the fondness for Style-1 may come from drawing areas by 
orto-/satellite imagery and thus leaving an empty stripe between adjacent 
fills - where a road goes between them, and is represented in the editor 
only by a thin centerline. According to such mappers, using a shared way 
for the road and the two fills is inaccurate as it does't leave for a 
physical width of the road, e.g., the fills cover land that are not 
forests, meadows, etc.

Another point comes from the shortcomings of a given editor (like iD). 
Though I can use JOSM and I use it for certain tasks, I prefer iD for 
everyday use. Nevertheless, I cannot do proper multipolygon editing in iD 
(to make sure everything is in the way I want it). I agree, we cannot force 
mappers to limit themselves to use a certain editor.

And yep, many activities of JM82 are considered as vandalism because it 
doesn't make the map more accurate while losing information from the 
previous state. E.g., obsoleteness/inaccuracy of the imported CLC MPs may 
be true but deleting them and drawing simple polygons at almost the same 
place - without on-field GPS survey... - is just not right. Adjusting MPs 
would do.

Ákos


On Friday, August 24, 2018 at 11:08:04 PM UTC+2, Gergely Matefi wrote:
>
> Hi,
>
> as far as I see, we have two different mapping styles (schools) for 
> landuse mapping.
>
> The first style (Style-1) is representing landuse areas with closed ways 
> (polygons), and prefers to keep separate ways for separate polygons. On 
> adjacent areas, only waypoints are shared, while ways kept separated, 
> resulting in overlapping ways at many boundaries. Such school is trying to 
> avoid multipolygons since there is no sense for building MP from a single 
> closed way.
>
> The second style (Style-2) is described as "Method B" in the Multipolygon 
> Wiki, Best Practices section [1]. That style prefers shared ways at land 
> cover boundaries, tries to avoid overlapping ways, and builds the landcover 
> from unclosed ways, listed in landuse multipolygons.
>
> Apparently, Style-1 is trying to eliminate MPs while Style-2 brings as 
> much MPs as needed.
>
> I went through at the global landuse mapping Wiki pages to get some 
> further hints. Both styles are properly described in the Wiki, and I 
> haven't found any direct statement that either of them is preferred over 
> the other one. From OSM user point of view, both styles are properly 
> rendered as long as avoids overlapping areas.
>
> It would be interesting to see the arguments why the German community 
> thinks that the first style is better than the second one. Is there any 
> strong reason, or is it just a convention for having a common style for 
> Germany ?
>
> In Hungary, we have many areas mapped according to Style-1, and we have 
> many ones which are mapped in accordance with Style-2. I see no severe 
> problem that those styles co-exist. I'd expect experienced mappers to be 
> able to handle both styles when making corrections.
>
> Since OSM users get the rendered maps rather than coping with the internal 
> representation, I don't see any user benefit in transforming areas from 
> Style-1 to Style-2 or vica versa, as long as the baseline is reasonably 
> accurate. Whenever the baseline is highly inaccurate or missing, I tend to 
> think that it is up to the mapper's discretion to use Style-1 or Style-2 
> after removing the improper baseline.
>
> I think the term "vandalism" was not referring to the style change itself, 
> but was referring to destroying existing and accurate landuse polygons 
> during this transformation without timely replacement. (As far as I 
> remember,  many "residential" areas were disappearing among many other 
> polygons)
>
> Regards,
> Gergely
>
> [1] https://wiki.openstreetmap.org/wiki/Relation:multipolygon
>
> On Fri, Aug 24, 2018 at 1:02 PM Gergely Matefi <gergely... at gmail.com 
> <javascript:>> wrote:
>
>> Hi,
>>
>> apart from the debate on the tagging style, we have several reasons while 
>> this issue is escalating, and we ought to improve on those areas in the 
>> future.
>>
>> 1) Destroying recent work of other editors without any a-priori discussion
>> OSM is built upon cooperation of thousands of mappers all over the world. 
>> Anyone is getting upset if her/his work is deleted without any apparent 
>> reason or without discussing the problem before. We should always seek for 
>> common resolution via contacting fellow mappers, even if it could be more 
>> time consuming in some cases. Destruction of work of other mappers could 
>> easily trigger 'edit wars' and should be only the last resort.
>>
>> 2) Destroying valid OSM data without immediate replacement
>> Main benefit for OSM user community relies in the accuracy and details of 
>> the OSM data, not on the tagging style itself. If we delete valid OSM 
>> elements just because we are disappointed with the tagging style, and if we 
>> don't recover the element immediately e.g. with a better tagging style, we 
>> may cause severe damages to our user community. Recovery after several 
>> months is simply too much time.
>>
>> 3) Tagging style transformation without consent with the local OSM 
>> community
>> There are many applications all over the world using OSM data, and no 
>> single mapper has visibility on all the usages. Whenever someone is 
>> attempting changing tagging style systematically, he or she should first 
>> negotiate with the OSM community responsible for that area to see that 
>> changes won't have adversarial impacts on applications.
>>
>> Regards,
>> Gergely
>>
>>
>>
>>
>> On Fri, Aug 24, 2018 at 12:31 PM Ferenc Veres <li... at netngine.hu 
>> <javascript:>> wrote:
>>
>>> It's difficult to review history of these areas (now), so the old CLC 
>>> import may not be related, but around 2012 we imported many landuse data 
>>> from EU's CLC database. (Just like many other countries did!) That 
>>> indeed created landuse that didn't cover the actual BING imagery well - 
>>> it's because different age and source of the CLC data and human errors 
>>> in creating that data. After importing more and more areas, we decided 
>>> this is creating useless data and we stopped. (We used different levels 
>>> of automatization vs manual correction. But the best result came from 
>>> simply not using CLC at all! I agree with you there.)
>>>
>>> Regarding MultiPoligons: we use a GIS-like approach here, where this 
>>> certain data type (land cover and land use) is about to form an 
>>> underlaying layer for the map, fully covering the world. Everything else 
>>> will be drawn over this layer of 100% cover. E.g. a street may be in a 
>>> town, forest, farmyard, or even on water if it's a bridge, but there is 
>>> always some ground base for the objects. Since OSM does not have this 
>>> approach defined (but nothing is making this impossible or bad - 
>>> basically the whole map (and every map) is like that!), we sometimes 
>>> have hard time to decide what objects are part of this "land use and 
>>> land cover" (e.g. recreation ground, park) or whether the area should be 
>>> subtracted from the larger area (multipoligon inner way).
>>>
>>> (If not subtracted, it's up to the render engines to figure out which of 
>>> two overlapping objects is up and which is down - which is bad data 
>>> design.)
>>>
>>> Thus we are not leaving empty 10 meters space between these elements, 
>>> like you do here:
>>>
>>> https://www.openstreetmap.org/way/579139233#map=17/46.91764/16.19432
>>>
>>> (In this example the surrounding ways are not part of neither the forest 
>>> or the farmland, usually we would adjoin areas, so that the roads go on 
>>> the farmland (or forest, which covers the reality best). Just like ways 
>>> running within the town are not left alone outside the town's polygon.)
>>>
>>> That requires millions of adjoining polygons - which would mean millions 
>>> of overlapping way objects. So the use of multipolygons is just a 
>>> logical optimization: every edge of this network will have only one line 
>>> object. Simple as that.
>>>
>>> No need to draw very long lines over other very long lines over and over 
>>> again, just draw everything once and use for two object's adjoining edge.
>>>
>>> Regarding difficulty in editing:
>>> 1. Editing tools should make this easier.
>>> 2. I agree that very big objects should be split and are bad.
>>> 3. Human errors don't make this method bad. It's a method that can be 
>>> learned and used and works very well if used right. (And please read 
>>> back to point "1." for beginners.)
>>>
>>> Regarding "vandalism": I think the guys refer to the method of deleting 
>>> big number of objects and creating them from scratch. We usually prefer 
>>> EDITING existing objects to throwing them away (and AFAIK this is basic 
>>> OSM rule).
>>>
>>> I didn't see the original landcover here, but if it's a raw CLC import, 
>>> completely deleting it may be reasonable. (Or over other bad edits, yes, 
>>> there is a place for such remake.)
>>>
>>> Regarding Alsószölnök: I found you draw adjoining farmyards as separate 
>>> items, I don't find this necessary.
>>>
>>> For example this:
>>>
>>> https://www.openstreetmap.org/way/579154541#map=18/46.89294/16.18852
>>>
>>> and to the North and South directly. This year they may be planted 
>>> different weeds but another year another species may change their look, 
>>> may make all the 3 identical. I think areas should be kept as big as 
>>> possible but within a few km limit.
>>>
>>> And in general, I think editing should respect the work of those who 
>>> regularly edit the area. Unless you fix plain errors, just changing 
>>> "editing style" is not reasonable. And I don't think there is "Hungarian 
>>> editing style". Even all these examples are similar:
>>>
>>> https://wiki.openstreetmap.org/wiki/Multipolygon_Examples
>>>
>>> The most specific example:
>>>
>>>
>>> https://wiki.openstreetmap.org/wiki/Multipolygon_Examples#Farmland_adjacent_to_forest_and_farmyard_adjacent_to_lake_.28Adjacent_multipolygons_and_adjacent_inner_areas.29
>>>
>>> Best regards,
>>> Ferenc
>>>
>>>
>>>
>>>
>>> 2018.08.24. 10:16 keltezéssel, Gergely Matefi írta:
>>> > Dear fellow Mappers,
>>> > 
>>> > JM82 provided a long answer to our critics in a changeset comment:
>>> > https://www.openstreetmap.org/changeset/61775261
>>> > 
>>> > I suggest to follow the discussion in this forum due to the wider 
>>> > audience. I encourage you to use English at this thread to allow JM82 
>>> to 
>>> > join to the discussions.
>>> > 
>>> > Regards,
>>> > Gergely
>>> > 
>>> > 
>>> > Kedves szerkesztőtársak,
>>> > 
>>> > JM82 írt egy hosszú választ a korábbi kritikáinkra, javasolnám a vitát 
>>> > ezen a fórumon folytatni. Lehetőleg angolul írjatok, hogy JM82 is 
>>> > csatlakozhasson.
>>> > 
>>> > Üdv,
>>> > Gergely
>>> > 
>>> > I would now like to comment on the allegations made here regarding 
>>> this 
>>> > changeset as follows:
>>> > In the OSM-Inpector 
>>> > (
>>> https://tools.geofabrik.de/osmi/?view=areas&lon=15.8752&lat=46.9491&zoom=12) 
>>>
>>> > there are regular errors with multi-polygons in this region, which 
>>> > unfortunately do not only affect this one CS, but the entire region 
>>> > around Szentgotthard. MPs are not closed, are faulty and often 
>>> > incorrectly set.
>>> > At this point, I would like to make a reference to the German OSM 
>>> Forum, 
>>> > where (exactly two years ago) exactly this problem is being discussed 
>>> on 
>>> > an ongoing basis. It is particularly bad in this region of HUN, as 
>>> here 
>>> > often every single field, every meadow is created as MP, which is also 
>>> > not a member of a real MP relation, but simply placed as MP alone. 
>>> This 
>>> > is according to the wiki of OSM, which also exists in English, not the 
>>> > intention of MPs and they should not be used like that either. Why and 
>>> > why does the HUN community shun here and describe it as a "Hungarian 
>>> > mapping style". In addition, these MPs / landuse areas do not 
>>> correspond 
>>> > to the aerial photos that are available via OSM today, but more on 
>>> that 
>>> > later. In short, the timeliness is not given.
>>> > That's one reason why I've deleted some MPs and replaced them with 
>>> > simple, usually much smaller, land areas.
>>> > 
>>> > It should also be noted that the OSM data in this region appears to 
>>> come 
>>> > from (semi-) automatic imports that were carried out many years ago. 
>>> > This leads in this context also to the problem of MPs in general and 
>>> > their use.
>>> > Another reason, in some areas of the area, is that MPs are already so 
>>> > large (in terms of both surface area and number of members) that 
>>> editing 
>>> > has become almost impossible for some editors. But that's exactly what 
>>> > OSM lives by: the timeliness of the data and its change! Landscapes 
>>> are 
>>> > changing, even in West HUN, land uses are changing (fields are turning 
>>> > into meadows and vice versa, towns are getting bigger, new buildings 
>>> are 
>>> > being added).
>>> > Smaller land areas are editable with all editors, changeable and so 
>>> on. 
>>> > Numerous MPs in this region are just that, because they have grown so 
>>> > big that nobody can handle them.
>>> > The next reason for my changes was that the JOSM editor constantly 
>>> > points to errors of MPs in this region as part of its review: 
>>> non-closed 
>>> > MPs, interchanged inner / outer relations. These are exactly the 
>>> errors 
>>> > that come along because of this excessive use of MPs, which - due to 
>>> the 
>>> > local landscape, should by no means be set in this way. For this 
>>> reason, 
>>> > I have also begun some time ago to bring the MPs in their extent as 
>>> well 
>>> > as the number of their members to a reasonably workable measure. 
>>> > Furthermore, I have corrected many Landuse tags for the existing 
>>> aerial 
>>> > images and erwweitert.
>>> > Likewise, for the sake of completeness, I would like to point out that 
>>> I 
>>> > am not against MPs per se, but they try a) to avoid, b) use sparingly 
>>> > and c) make changes if I am
>>> > Rather, OSM in this region was apparently imported semi-automatic 
>>> years 
>>> > ago and no one has taken this data, because these are not only often 
>>> > outdated (testing via Bing, geoimage.at <http://geoimage.at/> maxRes 
>>> or 
>>> > other image service providers), but also often inaccurately mapped. 
>>> > That's obvious
>>> > 
>>> > Another reason was the addition of landuse areas. As you can see 
>>> > clearly, I have supplemented numerous landuse areas (mostly fields, 
>>> but 
>>> > also meadows), since the quality and the mapping style in this region 
>>> is 
>>> > often catastrophic: over a few square kilometers simply arable land is 
>>> > stretched over it, with no aerial picture in it Are to be reconciled.
>>> > 
>>> > To the individual points further:
>>> > "Making huge changes with no comment is a terrible thing to start 
>>> with, 
>>> > and the fact that they are mostly simplifications".
>>> > OSM is a community, act like you are trying to be a member and not a 
>>> > destructor of it. "
>>> > I have not made any major changes in this CS by far, as can easily be 
>>> > understood. To change a MP or parts of it can hardly be called such.
>>> > 
>>> > Multipolygon-based landuse structure is adopted and preferred by the 
>>> > local OSM community and many other mappers follow that mapping style 
>>> > like this is a vandalism that does not make sense in the future. "
>>> > What is the meaning of mapping every single land area as an MP? The 
>>> > effort only increases, there is no recognizable added benefit of this 
>>> > measure. Only because I do not map land areas as MP - without 
>>> worsening 
>>> > the informative value of the data - is that in your opinion vandalism? 
>>> A 
>>> > strange, almost incomprehensible definition of vandalism.
>>> > Where did I make systematic changes here? I've added additional 
>>> Landuse 
>>> > tags and overhauled existing ones that did not fit together with the 
>>> > aerial photo altogether or not at all. That is verifiable by means of 
>>> > appropriate aerial photographs.
>>> > 
>>> > -- 
>>> > Magyar OSM Levelezőlista - openstreet... at googlegroups.com 
>>> <javascript:>
>>> > leiratkozás: openstreetmap-hungary+unsubscribe at googlegroups.com 
>>> <javascript:>
>>> > ---
>>> > Azért kapta ezt az üzenetet, mert feliratkozott a Google Csoportok 
>>> > „openstreetmap-hungary” csoportjára.
>>> > Az erről a csoportról és az ahhoz kapcsolódó e-mailekről való 
>>> > leiratkozáshoz küldjön egy e-amailt a(z) 
>>> > openstreetmap-hungary+unsubscribe at googlegroups.com <javascript:> 
>>> > <mailto:openstreetmap-hungary+unsubscribe at googlegroups.com 
>>> <javascript:>> címre.
>>> > További lehetőségekért látogasson el ide: 
>>> > https://groups.google.com/d/optout.
>>>
>>> -- 
>>> Magyar OSM Levelezőlista - openstreet... at googlegroups.com <javascript:>
>>> leiratkozás: openstreetmap-hungary+unsubscribe at googlegroups.com 
>>> <javascript:>
>>> --- 
>>> Azért kapta ezt az üzenetet, mert feliratkozott a Google Csoportok 
>>> szolgáltatásbeli openstreetmap-hungary csoportra.
>>> Az erről a csoportról és az ahhoz kapcsolódó e-mailekről való 
>>> leiratkozáshoz küldjön egy e-amailt a(z) 
>>> openstreetmap-hungary+unsubscribe at googlegroups.com <javascript:> címre.
>>> További lehetőségekért látogasson el a(z) 
>>> https://groups.google.com/d/optout címre.
>>>
>>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.openstreetmap.org/pipermail/talk-hu/attachments/20180825/8c66cba3/attachment.htm>