Markus Metz wrote:
> Moritz Lennert wrote:
>> On 30/11/11 18:37, Markus Metz wrote:
>>>
>>> Moritz Lennert wrote:
On 30/11/11 14:38, Markus Metz wrote:
>
>
> It seems to me that the confusion arises because you made use of
> features that allow you to skip topological clea
Hamish wrote:
> Ben wrote:
>> So from a user point of view, getting rid of "-c" in
>> GRASS 7 would remove another source of uncertainty.
>
> if that means that tasks like the ones I described
> in the third bullet point of this email:
> http://lists.osgeo.org/pipermail/grass-user/2011-December/06
Would it be a solution to add tolerance
for data with partial or bad topology to those vector
modules that deal with polygons and must not strictly
rely on error free topology? v.rast.stats is one
them. I imagine the group is not too large.
I don't think it would be very much work to change
the c
Ben wrote:
> So from a user point of view, getting rid of "-c" in
> GRASS 7 would remove another source of uncertainty.
if that means that tasks like the ones I described
in the third bullet point of this email:
http://lists.osgeo.org/pipermail/grass-user/2011-December/062818.html
are no longer
+1
If we remove -c, we can also get rid of the confusing
separate topology build paths (one default and one
for "-c") in the v.in.ogr source code.
In addition, polygon cleaning in v.in.ogr is based on
the original information in the unmodified OGR data
source. It seems to me that this is the one
Hi Roger,
I know you want to stop the discussion, just some last remarks,
including some for my motivation why I think topological cleaning
during import is absolutely necessary.
Roger André wrote:
> Hi Markus,
>
> My responses are inline.
>>
>>
>>
>> I would prefer to get this fixed instead of n
Benjamin Ducke wrote:
>
> Using data with unchecked topology is possible via "v.external".
> This module builds a pseudo topology that may be good enough in
> many cases. It works particularly well in GRASS 7.
Good point. In this case we could remove the -c flag for v.in.ogr in
trunk and always co
Hamish et al,
I'm well aware of how to set an alias, but I appreciate the suggestion.
Thank you.
I think there is a misunderstanding here. If you would all please go back
to the original question (which was posed by someone other than I), you
will see that it asks for clarification regarding how
Hi,
if the default behviour of v.in.ogr is not to your
taste, may I suggest to do:
echo "alias v.in.ogr='v.in.ogr -c'" >> ~/.grass.bashrc
but do so at your own risk.
fwiw, nothing black-box in the import process, just
search for "no_clean" here:
https://trac.osgeo.org/grass/browser/grass/tru
> be a strong expressed bias against other GIS systems which use a simple
> geometry model.
It was certainly not my intention to suggest that GRASS
is the only "proper" GIS.
Different GIS have different design philosophies.
Thus, they fit different use cases. I myself use
more than one.
> Ple
Hi Markus,
My responses are inline.
>
>
I would prefer to get this fixed instead of not cleaning during
> import. Can you provide sample data for testing?
>
Why spend time *fixing* this, unless you intend to eliminate the "-c" flag
altogether? It's not broken as far as I'm concerned. Mentally I
On Fri, Dec 2, 2011 at 1:15 PM, Maris Nartiss wrote:
> Hello,
> that makes sense.
>
> Might I suggest to take a look at JTS Topology Suite Technical
> Specifications fig. 6 that seems to display most common issues that
> could be eliminated with GRASS cleaning tools too.
Thanks for the suggestion
Hello,
that makes sense.
Might I suggest to take a look at JTS Topology Suite Technical
Specifications fig. 6 that seems to display most common issues that
could be eliminated with GRASS cleaning tools too.
Maris.
2011/12/2 Markus Metz :
> On Fri, Dec 2, 2011 at 12:43 PM, Maris Nartiss wrote:
>
On Fri, Dec 2, 2011 at 12:43 PM, Maris Nartiss wrote:
> Pardon my ignorance,
> how is possible to distinguish areas without centroids from holes?
> And why it doesn't make sense?
A hole is a nothing in a something. If there is no something all
around the hole there is no hole. IOW, an area withou
Pardon my ignorance,
how is possible to distinguish areas without centroids from holes?
And why it doesn't make sense?
Maris,
just finished converting and cleaning CAD (spaghetti) lines + points
to valid areas.
2011/12/2 Markus Metz :
>
> * for areas without centroids that are not holes. Areas w
Moritz Lennert wrote:
> On 30/11/11 18:37, Markus Metz wrote:
>>
>> Moritz Lennert wrote:
>>>
>>> On 30/11/11 14:38, Markus Metz wrote:
It seems to me that the confusion arises because you made use of
features that allow you to skip topological cleaning which is not the
def
Roger André wrote:
> By the way, it seems that the official stance is that it is preferred to
> allow the automatic cleaning of non-topological data sets when they are
> imported. However, I do want to point out that I have seen many, many
> instances where this auto-cleaning actually causes probl
On 30/11/11 18:37, Markus Metz wrote:
Moritz Lennert wrote:
On 30/11/11 14:38, Markus Metz wrote:
It seems to me that the confusion arises because you made use of
features that allow you to skip topological cleaning which is not the
default and not recommended.
Maybe this calls for a v.chec
By the way, it seems that the official stance is that it is preferred to
allow the automatic cleaning of non-topological data sets when they are
imported. However, I do want to point out that I have seen many, many
instances where this auto-cleaning actually causes problems, rather than
fixes them
Moritz Lennert wrote:
> On 30/11/11 14:38, Markus Metz wrote:
>>
>> It seems to me that the confusion arises because you made use of
>> features that allow you to skip topological cleaning which is not the
>> default and not recommended.
>
>
> Maybe this calls for a v.check.topology module ? Or an
I forced the -c flag to understand the side effects of doing it ;)
It's a common question in GRASS courses, where people get stuck when I
introduce the topology and their mind go to the mass of unclean data they
have :)
Things are clearer now to me. I was only confused by the fact that my
*valid n
On 30/11/11 14:38, Markus Metz wrote:
It seems to me that the confusion arises because you made use of
features that allow you to skip topological cleaning which is not the
default and not recommended.
Maybe this calls for a v.check.topology module ? Or an option in v.build
or v.clean which do
G. Allegri wrote:
> Mmm, sorry but I don't understand it.
> The topological correctness (in a general meaning, beyond GRASS) states that
> two polygons *cannot* overlap.
> GRASS topological model admits overlapping areas (the build tool doesn't
> complaint),
Only in special cases when areas were n
Mmm, sorry but I don't understand it.
The topological correctness (in a general meaning, beyond GRASS) states
that two polygons *cannot* overlap.
GRASS topological model admits overlapping areas (the build tool doesn't
complaint), but some modules produce wrong results with these areas. E.g.,
v.ras
G. Allegri wrote:
> Back again with my topological questions :)
>
> Two overlapping polygons were imported without cleaning them (-c option in
> v.in.ogr).
> The result are two overlapping areas, correctly built from two overlapping
> boundaries and their centroids.
> If I run v.build to output top
Back again with my topological questions :)
Two overlapping polygons were imported without cleaning them (-c option in
v.in.ogr).
The result are two overlapping areas, correctly built from two overlapping
boundaries and their centroids.
If I run v.build to output topological errors, the output is
26 matches
Mail list logo
