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

[Gergely Matefi]

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.matefi at gmail.com>
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 <lion at netngine.hu> 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 - openstreetmap-hungary at googlegroups.com
>> > leiratkozás: openstreetmap-hungary+unsubscribe at googlegroups.com
>> > ---
>> > 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
>> > <mailto:openstreetmap-hungary+unsubscribe at googlegroups.com> címre.
>> > További lehetőségekért látogasson el ide:
>> > https://groups.google.com/d/optout.
>>
>> --
>> Magyar OSM Levelezőlista - openstreetmap-hungary at googlegroups.com
>> leiratkozás: openstreetmap-hungary+unsubscribe at googlegroups.com
>> ---
>> 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 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/20180824/74cabdc3/attachment.htm>