[GRASS-user] v.generalize: strange behaviour on win?

Paolo_Cavallini · January 25, 2012, 10:03am

Hi all.
Commands like:

v.generalize input=province@Mapset_stefano type=area layer=1 -c
type=boundary method=douglas threshold=100000 look_ahead=7
reduction=50 slide=0.5 angle_thresh=3 degree_thresh=0
closeness_thresh=0 betweeness_thresh=0 alpha=1.0 beta=1.0 iterations=1
output=Province_general3

on Linux go well, whereas on windows some of the features are not simplified: see
https://int.faunalia.it/~paolo/generalize.zip
for an example.
Anyone confirms? Should I open a bug?
All the best.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc

Markus_GRASS · January 26, 2012, 7:53pm

On Wed, Jan 25, 2012 at 11:03 AM, Paolo Cavallini <cavallini@faunalia.it> wrote:

Hi all.
Commands like:

v.generalize input=province@Mapset_stefano type=area layer=1 -c
type=boundary method=douglas threshold=100000 look_ahead=7
reduction=50 slide=0.5 angle_thresh=3 degree_thresh=0
closeness_thresh=0 betweeness_thresh=0 alpha=1.0 beta=1.0 iterations=1
output=Province_general3

on Linux go well, whereas on windows some of the features are not simplified: see
https://int.faunalia.it/~paolo/generalize.zip
for an example.
Anyone confirms? Should I open a bug?

You would need to provide the input, not the output as an example.
Considering the detail of the output and the threshold used, it is no
surprise that not all boundaries were generalized because that would
break topology. If you want to generalize with a threshold of 100000,
I would recommend to first remove all areas with a size up to 100000.

Markus M

Paolo_Cavallini · January 27, 2012, 12:32pm

Il 26/01/2012 20:53, Markus Metz ha scritto:

You would need to provide the input, not the output as an example.

https://int.faunalia.it/~paolo/province.zip

Considering the detail of the output and the threshold used, it is no
surprise that not all boundaries were generalized because that would
break topology. If you want to generalize with a threshold of 100000,
I would recommend to first remove all areas with a size up to 100000.

This is not the point. The very same input and command work in Linux, leave
ungeneralized boundaries in Windows.
If you consider that also r.to.vect for lines also behaves differently between the
two OSs, I suspect an OS-specific bug here.

Any confirmation?
Thanks a lot.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc

Markus_GRASS · January 27, 2012, 6:02pm

On Fri, Jan 27, 2012 at 1:32 PM, Paolo Cavallini <cavallini@faunalia.it> wrote:

Il 26/01/2012 20:53, Markus Metz ha scritto:

You would need to provide the input, not the output as an example.

https://int.faunalia.it/~paolo/province.zip

Considering the detail of the output and the threshold used, it is no
surprise that not all boundaries were generalized because that would
break topology. If you want to generalize with a threshold of 100000,
I would recommend to first remove all areas with a size up to 100000.

This is not the point. The very same input and command work in Linux, leave
ungeneralized boundaries in Windows.

I tried v.generalize on the Province_general3 shapefile on Linux with
type=boundary method=douglas threshold=100000 and it did not modify
any boundaries. I also tried the input province shapefile and get the
same output. That is, if Province_general3 has been generated on
windows, I do get the same result on Linux, no difference between the
OS's. Are you using an older grass version on Linux?

Markus M

Paolo_Cavallini · January 27, 2012, 6:01pm

Il 27/01/2012 19:02, Markus Metz ha scritto:

same output. That is, if Province_general3 has been generated on
windows, I do get the same result on Linux, no difference between the
OS's. Are you using an older grass version on Linux?

aptitude show grass
Versione: 6.4.1-1
Thanks.

--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc

Markus_GRASS · January 27, 2012, 6:24pm

On Fri, Jan 27, 2012 at 7:01 PM, Paolo Cavallini <cavallini@faunalia.it> wrote:

Il 27/01/2012 19:02, Markus Metz ha scritto:

same output. That is, if Province_general3 has been generated on
windows, I do get the same result on Linux, no difference between the
OS's. Are you using an older grass version on Linux?

aptitude show grass
Versione: 6.4.1-1

v.generalize is broken in 6.4.1

Markus M

Paolo_Cavallini · January 28, 2012, 8:12am

Il 27/01/2012 19:24, Markus Metz ha scritto:

v.generalize is broken in 6.4.1

oh, so it's the different version - I didn't know v.generalize was changed recently,
thanks for letting me know. strangely enough, in Linux (6.4.1) it works well, whereas
in Windows (AFAIK 6.4.2RC3) it does not.
Any explanation?
All the best.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc

neteler · January 28, 2012, 9:09am

On Sat, Jan 28, 2012 at 9:12 AM, Paolo Cavallini <cavallini@faunalia.it> wrote:

Il 27/01/2012 19:24, Markus Metz ha scritto:

v.generalize is broken in 6.4.1

oh, so it's the different version - I didn't know v.generalize was changed recently,
thanks for letting me know. strangely enough, in Linux (6.4.1) it works well, whereas
in Windows (AFAIK 6.4.2RC3) it does not.
Any explanation?

Sure:
http://trac.osgeo.org/grass/changeset/46680

Maybe your analysis in 6.4.1 worked well but other generalization
methods failed.
Fixed in 6.4.2RC1. Here the "master" fixes:
http://trac.osgeo.org/grass/changeset/44899
http://trac.osgeo.org/grass/changeset/45172

It was omitted to be mentioned in the release notes, I have
added that now:
http://trac.osgeo.org/grass/wiki/Release/6.4.2RC1-News

Markus

Paolo_Cavallini · January 28, 2012, 9:24am

Il 28/01/2012 10:09, Markus Neteler ha scritto:

Any explanation?

Sure:
http://trac.osgeo.org/grass/changeset/46680

Maybe your analysis in 6.4.1 worked well but other generalization
methods failed.
Fixed in 6.4.2RC1. Here the "master" fixes:
http://trac.osgeo.org/grass/changeset/44899
http://trac.osgeo.org/grass/changeset/45172

Thanks for this. So we should expect the same behaviour on Debian as soon as 6.4.2
hits unstable, right? To me, this sounds like a bug.
All the best.

--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc

neteler · January 28, 2012, 9:51am

On Wed, Jan 25, 2012 at 11:03 AM, Paolo Cavallini <cavallini@faunalia.it> wrote:

Hi all.
Commands like:

v.generalize input=province@Mapset_stefano type=area layer=1 -c
type=boundary method=douglas threshold=100000 look_ahead=7
reduction=50 slide=0.5 angle_thresh=3 degree_thresh=0
closeness_thresh=0 betweeness_thresh=0 alpha=1.0 beta=1.0 iterations=1
output=Province_general3

on Linux go well, whereas on windows some of the features are not simplified: see
https://int.faunalia.it/~paolo/generalize.zip

Hint for non-Italians: Gauss-Boaga zone 1 projection.

for an example.
Anyone confirms? Should I open a bug?

I have tried it on Linux, 6.4.2RC3+, the result with the command you provided
the resulting map appears to be identical to the original map.

If that's a bug I don't know, it depends on the selected parameters?

MarkusN

neteler · January 28, 2012, 10:07am

On Sat, Jan 28, 2012 at 10:51 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Wed, Jan 25, 2012 at 11:03 AM, Paolo Cavallini <cavallini@faunalia.it> wrote:

Hi all.
Commands like:

I guess I found your problem:

v.generalize input=province@Mapset_stefano type=area layer=1 -c
type=boundary method=douglas threshold=100000 look_ahead=7

type=area ... type=boundary

...no good!

I agree that GRASS should complain but here I suppose that the
latter wins and hence the generalization fails.

I tried with area only and it looks good.

Markus

martinl · January 28, 2012, 10:36am

Hi,

2012/1/28 Markus Neteler <neteler@osgeo.org>:

v.generalize input=province@Mapset_stefano type=area layer=1 -c
type=boundary method=douglas threshold=100000 look_ahead=7

type=area ... type=boundary

...no good!

AFAIK the parser reads this combination as `type=area,boundary` in this case.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Markus_GRASS · January 28, 2012, 10:58am

On Sat, Jan 28, 2012 at 9:12 AM, Paolo Cavallini <cavallini@faunalia.it> wrote:

Il 27/01/2012 19:24, Markus Metz ha scritto:

v.generalize is broken in 6.4.1

oh, so it's the different version - I didn't know v.generalize was changed recently,
thanks for letting me know. strangely enough, in Linux (6.4.1) it works well, whereas
in Windows (AFAIK 6.4.2RC3) it does not.
Any explanation?

Yes. The quality of the result is judged by the integrity of the
output data. Therefore the result of 6.4.1 is bad and the result of
6.4.2 is good, contrary to your interpretation. You can try 6.4.1 with
the boundary_county vector in the North Carolina dataset and a
threshold of 100. Half of North Carolina disappears, the areas that
are left have mixed up attributes. That was fixed such that boundaries
are not generalized if the generalization would damage topology. For
your example vector I would recommend a much smaller threshold,
starting with 10, then maybe 20. You could easily end up with a much
higher reduction that with threshold = 100000.

Markus M

Paolo_Cavallini · January 29, 2012, 12:00pm

Il 28/01/2012 11:36, Martin Landa ha scritto:

type=area ... type=boundary

...no good!

AFAIK the parser reads this combination as `type=area,boundary` in this case.

the results are the same when using ara+boundary or boundary alone.
thanks.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc

Paolo_Cavallini · January 29, 2012, 12:12pm

Il 28/01/2012 11:58, Markus Metz ha scritto:

are left have mixed up attributes. That was fixed such that boundaries
are not generalized if the generalization would damage topology. For

OK, now I see. I think adding a warning in these case should be useful. Is this
documented in the man?
However, in my case topology is maintained, even if the areas are obviously overly
simplistic. On the other hand, I confirm that the attributes are mixed up.
Thanks a lot for the explanation.
All the best.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc

Roberto_Facoetti · January 29, 2012, 1:31pm

Hi mailing list

I have just installed the 6.4.2RC3 on a new computer (windows seven) and everything is working, as with the old one versions, but we I try, with the GUI wxpyhton to import vector or raster data, there is the following problem:

Traceback (most recent call last):
File "C:/OSGeo4W/apps/grass/grass-6.4.2RC3/etc/wxpython/wx
gui.py", line 1137, in OnImportGdalLayers

dlg = gdialogs.GdalImportDialog(parent = self)
File "C:\OSGeo4W\apps\grass\grass-6.4.2RC3\etc\wxpython\gu
i_modules\gdialogs.py", line 1253, in __init__

self.dsnInput = gselect.GdalSelect(parent = self, panel =
self.panel, ogr = ogr)
File "C:\OSGeo4W\apps\grass\grass-6.4.2RC3\etc\wxpython\gu
i_modules\gselect.py", line 1155, in __init__

ogr = ogr)
File "C:\OSGeo4W\apps\grass\grass-6.4.2RC3\etc\wxpython\gu
i_modules\gselect.py", line 957, in __init__

style = wx.CB_READONLY, **kwargs)
File "C:\OSGeo4W\apps\Python27\lib\site-packages\wx-2.8
-msw-unicode\wx\_controls.py", line 494, in __init__

_controls_.Choice_swiginit(self,_controls_.new_Choice(*args,
**kwargs))
wx._core
.
PyAssertionError
:
C++ assertion "!(style & wxCB_DROPDOWN) && !(style &
wxCB_READONLY) && !(style & wxCB_SIMPLE)" failed at
..\..\src\msw\choice.cpp(121) in wxChoice::Create(): this
style flag is ignored by wxChoice, you probably want to use
a wxComboBox

The other import windows (apart from import vector / raster ) are OK.

If I use the command console v.in.ogr etc. etc. all is working; it's only these two windows that are not working.

Any hints?

Thanks,

roberto

martinl · January 29, 2012, 1:44pm

HI,

2012/1/29 Roberto Facoetti <robifac@tiscali.it>:

I have just installed the 6.4.2RC3 on a new computer (windows seven) and
everything is working, as with the old one versions, but we I try, with the
GUI wxpyhton to import vector or raster data, there is the following
problem:

this bug has been recently fix in SVN. Could you try more recent build
[1] or `grass64-dev` in OSGeo4W.

Martin

[1] http://wingrass.fsv.cvut.cz/grass64/

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Markus_GRASS · January 30, 2012, 3:35pm

On Sun, Jan 29, 2012 at 1:12 PM, Paolo Cavallini <cavallini@faunalia.it> wrote:

Il 28/01/2012 11:58, Markus Metz ha scritto:

are left have mixed up attributes. That was fixed such that boundaries
are not generalized if the generalization would damage topology. For

OK, now I see. I think adding a warning in these case should be useful. Is this
documented in the man?

These cases are reported in verbose mode. This is not mentioned in the
manual. BTW, v.generalize in 6.4.2 and above behaves like v.clean
tool=prune since version 5.x, but offers far more methods. The
topology checks and skipping some boundaries if it is not possible to
safely generalize them is in this sense not new, but has been there
for many years.

However, in my case topology is maintained, even if the areas are obviously overly
simplistic.

My previous description was obviously incomplete. Output topology is
always correct, independent of the version. In 6.4.1, topologically
incorrect boundaries are deleted at the end of the module. In 6.4.2
and above, generalized boundaries are tested if they would damage
topology, if no, fine, if yes, the original is kept. Because in 6.4.1
the original boundaries are not kept and all incorrect generalized
boundaries are deleted, the output may suffer from heavy losses, i.e.
areas disappear (see nc example mentioned earlier and also your own
example).

Markus M

On the other hand, I confirm that the attributes are mixed up.

Thanks a lot for the explanation.
All the best.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc

Paolo_Cavallini · January 30, 2012, 3:56pm

Il 30/01/2012 16:35, Markus Metz ha scritto:

My previous description was obviously incomplete. Output topology is
always correct, independent of the version. In 6.4.1, topologically

Thanks Markus, this clarifies the issue a lot.
All the best.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc

neteler · January 30, 2012, 7:31pm

On Mon, Jan 30, 2012 at 4:56 PM, Paolo Cavallini <cavallini@faunalia.it> wrote:

Il 30/01/2012 16:35, Markus Metz ha scritto:

My previous description was obviously incomplete. Output topology is
always correct, independent of the version. In 6.4.1, topologically

Thanks Markus, this clarifies the issue a lot.

Please add important notes also to
http://grass.osgeo.org/wiki/V.generalize_tutorial

thanks
MarkusN