Opened 5 years ago

Closed 12 months ago

#2386 closed task (wontfix)

wxGUI: check for old vector topology format

Reported by: martinl Owned by: grass-dev@…
Priority: normal Milestone: 7.0.7
Component: wxGUI Version: unspecified
Keywords: v.build.all Cc:
CPU: Unspecified Platform: Unspecified

Description

Hi, I would assume that a common problem for users switching from G6 to G7 will be a new vector topo format. When opening vector data in G7 which were created in G6 d.vect fails with

WARNING: Old topology format version 5.0 is not supported by this
         release. Try to rebuild topology.

It would be nice to have in wxGUI mechanism/dialog which would inform user about that and suggest updating topology format to G7 automatically. This tool would

  1. switch to map's mapset on background
  2. call v.build or v.build.all
  3. switch back to current mapset and re-render display

Change History (14)

comment:1 in reply to:  description Changed 5 years ago by neteler

Replying to martinl:

It would be nice to have in wxGUI mechanism/dialog which would inform user about that and suggest updating topology format to G7 automatically.

Might it be better to also transfer to SQLite while we are at it?

http://grasswiki.osgeo.org/wiki/Convert_all_GRASS_6_vector_maps_to_GRASS_7

comment:2 Changed 5 years ago by wenzeslaus

Replying to martinl:

This tool would

  1. switch to map's mapset on background
  2. call v.build or v.build.all
  3. switch back to current mapset and re-render display

"Switch to" and "switch back" should be done by passing env parameter to the module calling function. In this way only the subprocess has the other mapset environment. There is even no "switch back" except from deleting the GRASS rc file which was passed to the subprocess. See e.g. r60376.

This is also something which could be in data catalog. However, I agree that the point is to have it easily accessible when the problem occurs.

comment:3 Changed 5 years ago by mlennert

Whatever the discussion, I don't think this is a "critical" bug. The message is clear, the solution (v.build) is clear and so it's more of a question of convenience.

As a first gut reaction, I would say don't do anything this fundamental "behind the user's back". I would think that most users won't switch wildly between grass6 and grass7 on the same data. If they do, v.build and v.build.all exist to help them.

Moritz

comment:4 in reply to:  3 ; Changed 5 years ago by martinl

Priority: criticalnormal

Replying to mlennert:

Whatever the discussion, I don't think this is a "critical" bug. The message is clear, the solution (v.build) is clear and so it's more of a question of convenience.

Right, decreasing the priority.

As a first gut reaction, I would say don't do anything this fundamental "behind the user's back". I would think that most users won't switch wildly between grass6 and grass7 on the same data. If they do, v.build and v.build.all exist to help them.

I modified the message in r65600 to mention v.build/v.build.all. If no objection I will do backport to relbr70.

comment:5 in reply to:  4 ; Changed 5 years ago by mlennert

Replying to martinl:

Replying to mlennert:

Whatever the discussion, I don't think this is a "critical" bug. The message is clear, the solution (v.build) is clear and so it's more of a question of convenience.

Right, decreasing the priority.

As a first gut reaction, I would say don't do anything this fundamental "behind the user's back". I would think that most users won't switch wildly between grass6 and grass7 on the same data. If they do, v.build and v.build.all exist to help them.

I modified the message in r65600 to mention v.build/v.build.all. If no objection I will do backport to relbr70.

+1

comment:6 in reply to:  5 Changed 5 years ago by martinl

Replying to mlennert:

I modified the message in r65600 to mention v.build/v.build.all. If no objection I will do backport to relbr70.

+1

done in r65601

comment:7 Changed 5 years ago by martinl

Probably we could have a new addon module called v.convert.g6 doing conversion from GRASS 6 to GRASS 7 (v.build + v.db.connect)?

comment:8 in reply to:  7 ; Changed 5 years ago by mlennert

Replying to martinl:

Probably we could have a new addon module called v.convert.g6 doing conversion from GRASS 6 to GRASS 7 (v.build + v.db.connect)?

might be a nice convenience module. But just v.db.connect won't be enough if you want to change from dbf to sqlite. The easiest would probably be db.connect + g.copy + g.rename, or something like that.

comment:9 in reply to:  8 ; Changed 5 years ago by martinl

Replying to mlennert:

Replying to martinl:

Probably we could have a new addon module called v.convert.g6 doing conversion from GRASS 6 to GRASS 7 (v.build + v.db.connect)?

might be a nice convenience module. But just v.db.connect won't be enough if you want to change from dbf to sqlite. The easiest would probably be db.connect + g.copy + g.rename, or something like that.

not really, see (1)

(1) http://grasswiki.osgeo.org/wiki/Convert_all_GRASS_6_vector_maps_to_GRASS_7

comment:10 in reply to:  9 Changed 5 years ago by mlennert

Replying to martinl:

Replying to mlennert:

Replying to martinl:

Probably we could have a new addon module called v.convert.g6 doing conversion from GRASS 6 to GRASS 7 (v.build + v.db.connect)?

might be a nice convenience module. But just v.db.connect won't be enough if you want to change from dbf to sqlite. The easiest would probably be db.connect + g.copy + g.rename, or something like that.

not really, see (1)

Right, forgot about v.db.reconnect.all.

comment:11 Changed 4 years ago by martinl

Milestone: 7.0.07.0.5

comment:12 Changed 3 years ago by neteler

Milestone: 7.0.57.0.6

comment:13 Changed 2 years ago by neteler

Milestone: 7.0.67.0.7

comment:14 Changed 12 months ago by martinl

Resolution: wontfix
Status: newclosed

No activity

Note: See TracTickets for help on using tickets.