Re: [GRASS-dev] Which is the correct WIND convention for creating a new mapset?

[Markus Metz]

On Wed, May 8, 2019 at 10:22 AM Panagiotis Mavrogiorgos 
wrote:
>
>
>
> On Tue, May 7, 2019 at 11:03 PM Markus Metz 
wrote:
>>
>>
>>
>> On Tue, May 7, 2019 at 10:20 AM Panagiotis Mavrogiorgos 
wrote:
>> >
>> >
>> >
>> > On Mon, May 6, 2019 at 9:38 PM Markus Metz <
markus.metz.gisw...@gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> On Mon, May 6, 2019 at 6:21 PM Panagiotis Mavrogiorgos <
pma...@gmail.com> wrote:
>> >> >
>> >> > Hello all,
>> >> >
>> >> > I am a bit confused WRT what the expected WIND should be when you
create a new mapset.
>> >>
>> >> > [...]
>> >>
>> >> > Is there an established convention?
>> >>
>> >> IMHO, new mapsets should use DEFAULT_WIND from PERMANENT.
>> >
>> >
>> > Thank you Markus, that's what I expected, too.
>> >
>> >>
>> >> But the current region of a new mapset is often adjusted, therefore
it does not really matter if DEFAULT_WIND or WIND is used.
>> >
>> >
>> > I don't disagree, but still, I don't see what's the benefit of not
using the same convention everywhere. Furthermore, I truly don't understand
why 4 different implementations are needed.
>>
>> True, g.mapset -c should be used whenever possible.
>
>
> I would argue that it is G_make_mapset() that should be used whenever
possible :)
> (which of course, is being used by g.mapset -c, too)

It depends. g.mapset changes the current mapset (and location and
database). It might also create a new mapset in an existing location, but
it always switches. If that switch is not desired, GISRC must be adjusted
to the original GRASS session. G_make_mapset() is a C function and should
be used by C modules. Of course you could use it with pygrass, but pygrass
initializes the GRASS C libraries, and you need to take care that
initializations are properly updated when changing mapsets (and locations).
Creating a new mapset in an existing location is not difficult: create the
folder and copy DEFAULT_WIND from PERMANENT to WIND in the new mapset.
Maybe create a new function create_mapset() in lib/python/script/utils.py?

>>> I adjusted the wxGUI startup wizard and the tests in trunk r74472,3
(the tests should use g.mapset -c, not yet implemented)
>
>
> I think that in the nc_spm_full_v2alpha dataset WIND and DEFAULT_WIND
differ, so 74473 might break any tests that don't explicitly set the region
themselves (which of course they should). We will see.

IMHO, tests need to set the region themselves, just as users. The current
region is such a fundamental concept of GRASS (raster processing) that I
regard it as a mistake if the current region is not explicitly set to
actual demands.

Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.to.db: next/prev line

[Markus Metz]

On Wed, May 8, 2019 at 2:34 PM Moritz Lennert 
wrote:
>
> On 8/05/19 11:44, Martin Landa wrote:
> > Hi,
> >
> > st 8. 5. 2019 v 11:31 odesílatel Moritz Lennert
> >  napsal:
> >> I don't think we have a tool for this currently. However, I'm not sure
that right and left are relevant terms for this case. Also: what do you do
in the case when three lines meet at a node. What would be the
'next_left_edge line' ?
> >
> > right, these terms comes from TopoGeo model based described in ISO
13249-3:2006.
> >
> > See eg.
> >
> > http://freegis.fsv.cvut.cz/gwiki/PostGIS_Topology
> >
https://trac.osgeo.org/postgis/attachment/ticket/3046/error_in_getRingedge.png
>
> Right. That does make sens. I didn't think of left and right in that way.
>
> I don't know what use cases are for this feature, compared to the ones I
> listed in my previous mail...

If I understand all this correctly, there is a next_left_edge,
next_right_edge,  previous_left_edge, previous_right_edge. Left would be
equivalent to going CW from the current node, right would be going CCW from
the current node. Next would be the end node, previous would be the start
node.

GRASS example (different from PostGIS terminology): if there are no other
lines connected at the start node of line 1, previous_left_edge =
next_edge_edge = 1, conforming to the GRASS topology model. The
corresponding function to get the next/previous line is
dig_angle_next_line().

Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1393: v.db.join and "duplicate column name"

[GRASS GIS]

#1393: v.db.join and "duplicate column name"
--+
  Reporter:  lucadelu |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.8.0
 Component:  Vector   |Version:  unspecified
Resolution:   |   Keywords:  vector db join
   CPU:  Unspecified  |   Platform:  All
--+
Changes (by mlennert):

 * milestone:  6.4.6 => 7.8.0


-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1393: v.db.join and "duplicate column name"

[GRASS GIS]

#1393: v.db.join and "duplicate column name"
--+
  Reporter:  lucadelu |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  6.4.6
 Component:  Vector   |Version:  unspecified
Resolution:   |   Keywords:  vector db join
   CPU:  Unspecified  |   Platform:  All
--+
Changes (by mlennert):

 * Attachment "v_db_join_colprefix.diff" added.


-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1393: v.db.join and "duplicate column name"

[GRASS GIS]

#1393: v.db.join and "duplicate column name"
--+
  Reporter:  lucadelu |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  6.4.6
 Component:  Vector   |Version:  unspecified
Resolution:   |   Keywords:  vector db join
   CPU:  Unspecified  |   Platform:  All
--+

Comment (by mlennert):

 I'm attaching a patch to the current Python version of v.db.join that does
 the following:

 * add a 'column_prefix' parameter that allows defining a column prefix for
 all newly joined columns in order to avoid any column name conflicts

 * never join the key column from the other table as that would be
 redundant

 Any objections against applying this ?

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.to.db: next/prev line

[Moritz Lennert]

On 8/05/19 11:44, Martin Landa wrote:

Hi,

st 8. 5. 2019 v 11:31 odesílatel Moritz Lennert
 napsal:

I don't think we have a tool for this currently. However, I'm not sure that 
right and left are relevant terms for this case. Also: what do you do in the 
case when three lines meet at a node. What would be the 'next_left_edge line' ?


right, these terms comes from TopoGeo model based described in ISO 13249-3:2006.

See eg.

http://freegis.fsv.cvut.cz/gwiki/PostGIS_Topology
https://trac.osgeo.org/postgis/attachment/ticket/3046/error_in_getRingedge.png


Right. That does make sens. I didn't think of left and right in that way.

I don't know what use cases are for this feature, compared to the ones I 
listed in my previous mail...


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.to.db: next/prev line

[Martin Landa]

Hi,

st 8. 5. 2019 v 11:31 odesílatel Moritz Lennert
 napsal:
> I don't think we have a tool for this currently. However, I'm not sure that 
> right and left are relevant terms for this case. Also: what do you do in the 
> case when three lines meet at a node. What would be the 'next_left_edge line' 
> ?

right, these terms comes from TopoGeo model based described in ISO 13249-3:2006.

See eg.

http://freegis.fsv.cvut.cz/gwiki/PostGIS_Topology
https://trac.osgeo.org/postgis/attachment/ticket/3046/error_in_getRingedge.png

Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.to.db: next/prev line

[Moritz Lennert]

Hi Martin,

Am 8. Mai 2019 08:29:22 MESZ schrieb Martin Landa :
>Hi,
>
>I wonder whether there is a tool in GRASS which enables writing to
>attribute table information about next/previous lines. Basically info
>about next_right_edge/next_left_edge.
>
>My idea is to extend `v.to.db` option `sides` to work also for lines.
>
>v.to.db mysoils option=roads columns=left,right layer=2
>
>would write into `left` column next_left_edge line category, similarly
>for `right` column.
>
>Does it make sense to you or I am simply overlooking some existing
>tool in GRASS?



I don't think we have a tool for this currently. However, I'm not sure that 
right and left are relevant terms for this case. Also: what do you do in the 
case when three lines meet at a node. What would be the 'next_left_edge line' ?

I think this needs a little bit more thinking through...

I think a connectivity matrix between lines could be a possible alternative, as 
was recently discussed on the lists. Or possibly some form of association table 
node cats <-> line cats, knowing that will be n-to-n, so maybe best not to be 
directly integrated into the layers attribute table at least not the nodes' 
table. From the perspective of lines, one related lower hanging fruit I thought 
about was to extend v.to.db to include start_cat, stop_cat in addition to the 
current start/stop which provide the coordinates of nodes. This would then 
allow to easily identify lines that share common nodes.

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Which is the correct WIND convention for creating a new mapset?

[Panagiotis Mavrogiorgos]

On Tue, May 7, 2019 at 11:03 PM Markus Metz 
wrote:

>
>
> On Tue, May 7, 2019 at 10:20 AM Panagiotis Mavrogiorgos 
> wrote:
> >
> >
> >
> > On Mon, May 6, 2019 at 9:38 PM Markus Metz <
> markus.metz.gisw...@gmail.com> wrote:
> >>
> >>
> >>
> >> On Mon, May 6, 2019 at 6:21 PM Panagiotis Mavrogiorgos <
> pma...@gmail.com> wrote:
> >> >
> >> > Hello all,
> >> >
> >> > I am a bit confused WRT what the expected WIND should be when you
> create a new mapset.
> >>
> >> > [...]
> >>
> >> > Is there an established convention?
> >>
> >> IMHO, new mapsets should use DEFAULT_WIND from PERMANENT.
> >
> >
> > Thank you Markus, that's what I expected, too.
> >
> >>
> >> But the current region of a new mapset is often adjusted, therefore it
> does not really matter if DEFAULT_WIND or WIND is used.
> >
> >
> > I don't disagree, but still, I don't see what's the benefit of not using
> the same convention everywhere. Furthermore, I truly don't understand why 4
> different implementations are needed.
>
> True, g.mapset -c should be used whenever possible.
>

I would argue that it is G_make_mapset() that should be used whenever
possible :)
(which of course, is being used by g.mapset -c, too)

I adjusted the wxGUI startup wizard and the tests in trunk r74472,3 (the
> tests should use g.mapset -c, not yet implemented)
>

I think that in the nc_spm_full_v2alpha dataset WIND and DEFAULT_WIND
differ, so 74473 might break any tests that don't explicitly set the region
themselves (which of course they should). We will see.

P.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev