Vector FAQ GRASS6 - Revision history

Neteler at 10:17, 4 December 2018

2018-12-04T10:17:17Z

← Older revision		Revision as of 10:17, 4 December 2018
Line 21:		Line 21:

	'''Q''': Is it possible to write/edit non native formats like shapefile, coverage or PostGIS?<br>		'''Q''': Is it possible to write/edit non native formats like shapefile, coverage or PostGIS?<br>
	'''A''': yes: {{cmd\|v.out.ogr}} and from GRASS 7 onwards, {{cmd\|v.external~~\|version=70~~}}		'''A''': yes: {{cmd\|v.out.ogr}} and from GRASS 7 onwards, {{cmd\|v.external}}

	'''Q''': Why are two line types (line and boundary) needed? Everything is easier with just one type, otherwise thousands of hours must be spent to assign the right type to each line.<br>		'''Q''': Why are two line types (line and boundary) needed? Everything is easier with just one type, otherwise thousands of hours must be spent to assign the right type to each line.<br>

Neteler: updated

2013-03-19T17:14:04Z

updated

← Older revision		Revision as of 17:14, 19 March 2013
Line 1:		Line 1:
	'''Q''':GRASS 6 vector architecture - FAQ: Why on earth topological model!? It introduces in fact many problems. Nontopological GIS is easier to use and all popular proprietary GIS desktops like ArcView or Mapinfo use nontopological model. But there are some advantages of topological model over nontopological. In addition, OpenGIS specification is not topological, so GRASS may never conform Open GIS once topological model is used.<br>		'''Q''':GRASS 6 vector architecture - FAQ: Why on earth a topological model!? It introduces in fact many problems. Nontopological GIS is easier to use and all popular proprietary GIS desktops like ArcView or Mapinfo use nontopological model. But there are some advantages of topological model over nontopological. In addition, OpenGIS specification is not topological, so GRASS may never conform Open GIS once topological model is used.<br>
	'''A''': Well...		'''A''': Well, we just prefer quality.

	'''Q''': ~~Oh my God, how can you handle attributes and geometry by two separate libraries~~? ~~This way can never write reliable implementation and there will be always inconsistencies between geometry and attributes.~~<br>		'''Q''': What are the programming details?<br>
	'''A''': ~~Solved since the 'cat' column is linking both (also stored in the geometric part)~~.		'''A''': See here: http://grass.osgeo.org/programming7/vlibFAQ.html

	'''Q''': Everything is going RDBMS. The only modern and good enough solution is to store all data in relational database. Why do you spend all that time working on grass vector format if you can use PostGIS/Postgres?<br>		'''Q''': Everything is going RDBMS. The only modern and good enough solution is to store all data in relational database. Why do you spend all that time working on grass vector format if you can use PostGIS/Postgres?<br>
	'''A''': ~~mmm...~~Its a matter of choice. GRASS support [[PostGIS]]/~~Postgres~~.		'''A''': Its' a matter of choice. And GRASS GIS support [[PostGIS]]/PostgreSQL. You can choose the database backend, and in GRASS 7 a direct integration has been implemented. Note that GRASS's vector format is topological, which opens the doors to all sorts of analyses which a non-topological format (like SHAPE) does not. And you can link a vector to an external RDBMS with {{cmd\|v.db.connect}} or use directly a PostGIS data source with {{cmd\|v.external}}.
	You can choose that~~. But supporting other formats is not bad!~~ GRASS's vector format is topological, which opens doors to all sorts of analyses which a non-topological format (like ~~PostGIS~~) does not. ~~You~~ can ~~still~~ link a vector to an external RDBMS with {{cmd\|v.db.connect}} or directly to a PostGIS data source with {{cmd\|v.external}}.

	'''Q''': Why can't I have layers called 1516?<BR>		'''Q''': Why can't I have layers called 1516?<BR>
Line 13:		Line 12:

	'''Q''': Can you save color rules in vector files?<br>		'''Q''': Can you save color rules in vector files?<br>
	'''A''': Yes, see GRASSRGB column in the {{cmd\|d.vect}} manual page		'''A''': Yes, see GRASSRGB column in the {{cmd\|d.vect}} manual page and {{cmd\|v.colors}}

	'''Q''': It is well known that ~~{{cmd\|v.support}} in GRASS 5 often reported~~ errors ~~and cannot build topology~~. ~~Is this problem addressed in GRASS 6~~?<br>		'''Q''': It is well known that SHAPE files may contain topological errors. What can I do?<br>
	'''A''': ~~Yes~~. {{cmd\|v.build}} ~~is way better~~		'''A''': GRASS helps you: the {{cmd\|v.in.ogr}} import cleans most problems, furthermore there are {{cmd\|v.build}} which offers an error map as well as {{cmd\|v.clean}} and {{cmd\|v.edit}} for special problems.

	'''Q''': Why do we need support for so many formats and databases? ~~One~~ format + one database is enough.<br>		'''Q''': Why do we need support for so many formats and databases? I think that one format + one database is enough.<br>
	'''A''': Again ~~its~~ a matter of choice. What's wrong with supporting several formats?		'''A''': Again it is a matter of choice. What's wrong with supporting several formats?

	'''Q''': Is it possible to write/edit non native formats like shapefile, coverage or PostGIS?<br>		'''Q''': Is it possible to write/edit non native formats like shapefile, coverage or PostGIS?<br>
	'''A''': yes: {{cmd\|v.out.ogr}}		'''A''': yes: {{cmd\|v.out.ogr}} and from GRASS 7 onwards, {{cmd\|v.external\|version=70}}

	'''Q''': Why are two line types (line and boundary) needed? Everything is easier with just one type, otherwise thousands of hours must be spent to assign the right type to each line.<br>		'''Q''': Why are two line types (line and boundary) needed? Everything is easier with just one type, otherwise thousands of hours must be spent to assign the right type to each line.<br>
Line 28:		Line 27:

	'''Q''': Is it possible to generate TIN from raster DEM or 3D points?<br>		'''Q''': Is it possible to generate TIN from raster DEM or 3D points?<br>
	'''A''': ~~more~~ or less. Not exciting yet, ~~you~~ are ~~welcome to contribute~~. See also [[Addons]]		'''A''': More or less. Not exciting yet, but TINs are also not too exciting. See also [[Addons]]

	'''Q''': Are there volumes or other 3D objects supported?<br>		'''Q''': Are there volumes or other 3D objects supported?<br>
Line 52:		Line 51:

	'''Q''': Are there routes like in ArcInfo supported?<br>		'''Q''': Are there routes like in ArcInfo supported?<br>
	'''A''': yes (see {{cmd\|d.path}}, v.net., v.lrs.)		'''A''': yes (see {{cmd\|d.path}}, {{cmd\|v.net}}., {{cmd\|v.lrs}}.)

	'''Q''': Will be possible to read attributes from ArcInfo coverages?<br>		'''Q''': Will be possible to read attributes from ArcInfo coverages?<br>
Line 58:		Line 57:

	'''Q''': Where can I find a description of the new vector format?<br>		'''Q''': Where can I find a description of the new vector format?<br>
	'''A''': Try http://www.ing.unitn.it/~grass/conferences/GRASS2002/proceedings/proceedings/pdfs/Blazek_Radim.pdf and http://~~download~~.osgeo.org/~~grass/grass6_progman/~~ ("GRASS 6 Vector Architecture")		'''A''': Try http://www.ing.unitn.it/~grass/conferences/GRASS2002/proceedings/proceedings/pdfs/Blazek_Radim.pdf and http://grass.osgeo.org/programming7 ("GRASS GIS Vector Architecture")

	[[Category:FAQ]]		[[Category:FAQ]]
	[[Category:Vector]]		[[Category:Vector]]

Neteler at 00:32, 7 December 2011

2011-12-07T00:32:07Z

← Older revision		Revision as of 00:32, 7 December 2011
Line 61:		Line 61:

	[[Category:FAQ]]		[[Category:FAQ]]
			[[Category:Vector]]

Neteler at 20:12, 14 November 2010

2010-11-14T20:12:54Z

← Older revision		Revision as of 20:12, 14 November 2010
Line 43:		Line 43:

	'''Q''': Is it supported Microsoft SQL Server / Oracle / Informix?<br>		'''Q''': Is it supported Microsoft SQL Server / Oracle / Informix?<br>
	'''A''': Oracle via OGR, Microsoft via ODBC, see {{cmd\|~~grass-~~sql}}		'''A''': Oracle via OGR, Microsoft via ODBC, see {{cmd\|sql}}

	'''Q''': Are there images and other arbitrary documents supported as attributes?<br>		'''Q''': Are there images and other arbitrary documents supported as attributes?<br>

⚠️HamishBowman: br

2009-12-30T01:59:09Z

← Older revision		Revision as of 01:59, 30 December 2009
Line 9:		Line 9:
	You can choose that. But supporting other formats is not bad! GRASS's vector format is topological, which opens doors to all sorts of analyses which a non-topological format (like PostGIS) does not. You can still link a vector to an external RDBMS with {{cmd\|v.db.connect}} or directly to a PostGIS data source with {{cmd\|v.external}}.		You can choose that. But supporting other formats is not bad! GRASS's vector format is topological, which opens doors to all sorts of analyses which a non-topological format (like PostGIS) does not. You can still link a vector to an external RDBMS with {{cmd\|v.db.connect}} or directly to a PostGIS data source with {{cmd\|v.external}}.

	'''Q''': Why can't I have layers called 1516?		'''Q''': Why can't I have layers called 1516?<BR>
	'''A''': The naming convention for vector maps requires that map names start with a character, not a number (map name scheme: [A-Za-z][A-Za-z0-9_]*). Reason: GRASS uses SQL which does not permit names starting with a number or symbol.		'''A''': The naming convention for vector maps requires that map names start with a character, not a number (map name scheme: [A-Za-z][A-Za-z0-9_]*). Reason: GRASS uses SQL which does not permit names starting with a number or symbol.

Neteler: naming convention for vector maps, use of {{cmd|xx}} template

2009-04-07T09:50:23Z

naming convention for vector maps, use of {{cmd|xx}} template

⚠️HamishBowman: postgis

2008-09-11T00:09:52Z

postgis

← Older revision		Revision as of 00:09, 11 September 2008
Line 4:		Line 4:
	'''Q''': Oh my God, how can you handle attributes and geometry by two separate libraries? This way can never write reliable implementation and there will be always inconsistencies between geometry and attributes.<br>		'''Q''': Oh my God, how can you handle attributes and geometry by two separate libraries? This way can never write reliable implementation and there will be always inconsistencies between geometry and attributes.<br>
	'''A''': Solved since the 'cat' column is linking both (also stored in the geometric part).		'''A''': Solved since the 'cat' column is linking both (also stored in the geometric part).


	'''Q''': Everything is going RDBMS. The only modern and good enough solution is to store all data in relational database. Why do you spend all that time working on grass vector format if you can use PostGIS/Postgres?<br>		'''Q''': Everything is going RDBMS. The only modern and good enough solution is to store all data in relational database. Why do you spend all that time working on grass vector format if you can use PostGIS/Postgres?<br>
	'''A''': mmm...Its a matter of choice. GRASS support [[PostGIS]]/Postgres.		'''A''': mmm...Its a matter of choice. GRASS support [[PostGIS]]/Postgres.
	You can choose that. But supporting other formats is not bad! GRASS's vector format is topological, which opens doors to all sorts of analyses which a non-topological format (like PostGIS does not.		You can choose that. But supporting other formats is not bad! GRASS's vector format is topological, which opens doors to all sorts of analyses which a non-topological format (like PostGIS) does not. You can still link a vector to an external RDBMS with {{cmd\|v.db.connect}} or directly to a PostGIS data source with {{cmd\|v.external}}.


	'''Q''': Is save color in vector files?<br>		'''Q''': Can you save color rules in vector files?<br>
	'''A''': Yes, see d.vect manual page		'''A''': Yes, see GRASSRGB column in the {{cmd\|d.vect}} manual page

	'''Q''': It is well known that v.support often reports errors and cannot build topology. Is this problem addressed in GRASS 6?<br>		'''Q''': It is well known that v.support often reports errors and cannot build topology. Is this problem addressed in GRASS 6?<br>

⚠️HamishBowman: link

2008-09-11T00:07:44Z

link

← Older revision		Revision as of 00:07, 11 September 2008
Line 6:		Line 6:

	'''Q''': Everything is going RDBMS. The only modern and good enough solution is to store all data in relational database. Why do you spend all that time working on grass vector format if you can use PostGIS/Postgres?<br>		'''Q''': Everything is going RDBMS. The only modern and good enough solution is to store all data in relational database. Why do you spend all that time working on grass vector format if you can use PostGIS/Postgres?<br>
	'''A''': mmm...Its a matter of choice. GRASS support PostGIS/Postgres.		'''A''': mmm...Its a matter of choice. GRASS support [[PostGIS]]/Postgres.
	You can choose that. But supporting other formats is not bad!		You can choose that. But supporting other formats is not bad! GRASS's vector format is topological, which opens doors to all sorts of analyses which a non-topological format (like PostGIS does not.

	'''Q''': Is save color in vector files?<br>		'''Q''': Is save color in vector files?<br>

Neteler: Vector Faq GRASS57 moved to Vector FAQ GRASS6: 5.7 -> 6

2007-02-06T13:26:49Z

Vector Faq GRASS57 moved to Vector FAQ GRASS6: 5.7 -> 6

← Older revision		Revision as of 13:26, 6 February 2007
(No difference)

Neteler: updated

2007-02-06T13:26:22Z

updated

← Older revision		Revision as of 09:50, 7 April 2009
Line 4:		Line 4:
	'''Q''': Oh my God, how can you handle attributes and geometry by two separate libraries? This way can never write reliable implementation and there will be always inconsistencies between geometry and attributes.<br>		'''Q''': Oh my God, how can you handle attributes and geometry by two separate libraries? This way can never write reliable implementation and there will be always inconsistencies between geometry and attributes.<br>
	'''A''': Solved since the 'cat' column is linking both (also stored in the geometric part).		'''A''': Solved since the 'cat' column is linking both (also stored in the geometric part).


	'''Q''': Everything is going RDBMS. The only modern and good enough solution is to store all data in relational database. Why do you spend all that time working on grass vector format if you can use PostGIS/Postgres?<br>		'''Q''': Everything is going RDBMS. The only modern and good enough solution is to store all data in relational database. Why do you spend all that time working on grass vector format if you can use PostGIS/Postgres?<br>
Line 10:		Line 9:
	You can choose that. But supporting other formats is not bad! GRASS's vector format is topological, which opens doors to all sorts of analyses which a non-topological format (like PostGIS) does not. You can still link a vector to an external RDBMS with {{cmd\|v.db.connect}} or directly to a PostGIS data source with {{cmd\|v.external}}.		You can choose that. But supporting other formats is not bad! GRASS's vector format is topological, which opens doors to all sorts of analyses which a non-topological format (like PostGIS) does not. You can still link a vector to an external RDBMS with {{cmd\|v.db.connect}} or directly to a PostGIS data source with {{cmd\|v.external}}.

			'''Q''': Why can't I have layers called 1516?
			'''A''': The naming convention for vector maps requires that map names start with a character, not a number (map name scheme: [A-Za-z][A-Za-z0-9_]*). Reason: GRASS uses SQL which does not permit names starting with a number or symbol.

	'''Q''': Can you save color rules in vector files?<br>		'''Q''': Can you save color rules in vector files?<br>
	'''A''': Yes, see GRASSRGB column in the {{cmd\|d.vect}} manual page		'''A''': Yes, see GRASSRGB column in the {{cmd\|d.vect}} manual page

	'''Q''': It is well known that v.support often ~~reports~~ errors and cannot build topology. Is this problem addressed in GRASS 6?<br>		'''Q''': It is well known that {{cmd\|v.support}} in GRASS 5 often reported errors and cannot build topology. Is this problem addressed in GRASS 6?<br>
	'''A''': Yes. v.build is way better		'''A''': Yes. {{cmd\|v.build}} is way better

	'''Q''': Why do we need support for so many formats and databases? One format + one database is enough.<br>		'''Q''': Why do we need support for so many formats and databases? One format + one database is enough.<br>
Line 21:		Line 22:

	'''Q''': Is it possible to write/edit non native formats like shapefile, coverage or PostGIS?<br>		'''Q''': Is it possible to write/edit non native formats like shapefile, coverage or PostGIS?<br>
	'''A''': yes: v.out.ogr		'''A''': yes: {{cmd\|v.out.ogr}}

	'''Q''': Why are two line types (line and boundary) needed? Everything is easier with just one type, otherwise thousands of hours must be spent to assign the right type to each line.<br>		'''Q''': Why are two line types (line and boundary) needed? Everything is easier with just one type, otherwise thousands of hours must be spent to assign the right type to each line.<br>
	'''A''': If you have lines which are part of areas and lines which are not part of area (Example: roads, rivers etc) how ~~can~~ you distinguish them?		'''A''': If you have lines which are part of areas and lines which are not part of area (Example: roads, rivers etc) how could you distinguish them?

	'''Q''': Is it possible to generate TIN from raster DEM or 3D points?<br>		'''Q''': Is it possible to generate TIN from raster DEM or 3D points?<br>
	'''A''': more or less. Not exciting yet, you are welcome to contribute		'''A''': more or less. Not exciting yet, you are welcome to contribute. See also [[Addons]]

	'''Q''': Are there volumes or other 3D objects supported?<br>		'''Q''': Are there volumes or other 3D objects supported?<br>
	'''A''': 3D faces yes (e.g. CAD-style 3D buildings etc), use v.in.ogr or v.in.dxf to import or v.extrude to extrude from 2D.		'''A''': 3D faces yes (e.g. CAD-style 3D buildings etc), use {{cmd\|v.in.ogr}} or {{cmd\|v.in.dxf}} to import or {{cmd\|v.extrude}} to extrude from 2D.

	'''Q''': Are there multiobjects like multipoint or multiline supported?<br>		'''Q''': Are there multiobjects like multipoint or multiline supported?<br>
	'''A''': Yes - v.build.polyline		'''A''': Yes - {{cmd\|v.build.polyline}}

	'''Q''': Does any support for overlay/analyses exist in GRASS 6?<br>		'''Q''': Does any support for overlay/analyses exist in GRASS 6?<br>
	'''A''': yes - v.overlay and v.select		'''A''': yes - {{cmd\|v.overlay}} and {{cmd\|v.select}}

	'''Q''': Why do we need more categories attached to one element?<br>		'''Q''': Why do we need more categories attached to one element?<br>
Line 42:		Line 43:

	'''Q''': Is it supported Microsoft SQL Server / Oracle / Informix?<br>		'''Q''': Is it supported Microsoft SQL Server / Oracle / Informix?<br>
	'''A''': Oracle via OGR, Microsoft via ODBC		'''A''': Oracle via OGR, Microsoft via ODBC, see {{cmd\|grass-sql}}

	'''Q''': Are there images and other arbitrary documents supported as attributes?<br>		'''Q''': Are there images and other arbitrary documents supported as attributes?<br>
	'''A''': no (not yet?)		'''A''': no (not yet?). Perhaps add blob support?

	'''Q''': How can be nontopological formats read by topological GIS without conversion?<br>		'''Q''': How can be nontopological formats read by topological GIS without conversion?<br>
	'''A''': pseudotopology is built - v.external		'''A''': pseudotopology is built - {{cmd\|v.external}}

	'''Q''': Are there routes like in ArcInfo supported?<br>		'''Q''': Are there routes like in ArcInfo supported?<br>
	'''A''': yes (see d.path, v.net., v.lrs.)		'''A''': yes (see {{cmd\|d.path}}, v.net., v.lrs.)

	'''Q''': Will be possible to read attributes from ArcInfo coverages ~~once OGR formats are supported~~?<br>		'''Q''': Will be possible to read attributes from ArcInfo coverages?<br>
	'''A''': yes, use v.in.ogr		'''A''': yes, use {{cmd\|v.in.ogr}}

	'''Q''': Where can I find a description of the new vector format?<br>		'''Q''': Where can I find a description of the new vector format?<br>
	'''A''': Try http://www.ing.unitn.it/~grass/conferences/GRASS2002/proceedings/proceedings/pdfs/Blazek_Radim.pdf and http://~~grass~~.~~itc~~.it/~~devel~~/~~index.php#prog~~		'''A''': Try http://www.ing.unitn.it/~grass/conferences/GRASS2002/proceedings/proceedings/pdfs/Blazek_Radim.pdf and http://download.osgeo.org/grass/grass6_progman/ ("GRASS 6 Vector Architecture")


	[[Category:FAQ]]		[[Category:FAQ]]