GRASS-Wiki - User contributions [en]

Turns in the vector network analysis

2020-06-09T23:46:22Z

⚠️Turek:

__TOC__

The turntable can be created by {{cmd|v.net}} module, which is one of [[vector network analysis]] modules.
Building the turntable allows you to model e.g. traffic code, where some turns may be prohibited.
It creates a turntable with the costs for every possible turn on every possible node (intersection, crossroad) in given layer. U-turns are taken in account too.

[[Image:Line_graph.png|center|400px|thumb| Author: Stephan Winter]]

For better handling, a linegraph is created. In this linegraph, every line is represented by two nodes. These nodes have positive and negative values respectively, with their absolute values identical. Every node corresponds to opposite line direction. The positive node matches the direction of line. The negative node matches the opposite direction. For better understanding, let's have a travelling subject standing on a line (road) before an intersection wanting to cross it. This line's direction is TOWARDS the intersection. Travelling from this line through the intersection means that the subject is currently standing on the POSITIVE node representation of the line. After crossing to this line from any permitted direction, the subject gets to the NEGATIVE point representation of the line.

These two nodes (corresponding to the same line) are connected with two U-turns (for both directions). Every U-turn direction belongs to another intersection. U-turn from the POSITIVE node to the NEGATIVE one belongs to the intersection we are going to cross. The other U-turn belongs to the intersection at the opposite end of this line.

'''If features in analyzed network are changed, the turntable must be created again (e.g. it includes v.net connect operation). '''

==Turntable description==

Every record in the turntable represents one turn.

'''Columns description:'''

* '''cat''' – category in '''tlayer''' (layer with turntable), which corresponds to both lines in turn

* '''ln_from''' – unique category in '''tuclayer''' layer assigned to the starting line of the turn

* '''ln_to''' – unique category in '''tuclayer''' layer assigned to the ending line line of the turn

* '''cost''' – cost for turn (integer or double), assign -1 to close the turn

* '''isec''' – point category in '''tulayer''' layer, which represents the intersection, where the turn belongs

* '''angle''' – angle between the lines before and after the intersection (radians), positive -> turn to the right, negative -> turn to the left, 0 -> straight

[[Image:Turntable.png|center|800px|thumb]]

Every possible turn on any possible intersection is represented by unique record (line).
In the picture above you can see the turntable and part of vector layer with highlighted turn from the line with unique category 289 through the node (intersection) 561 to the line with unique category 234. In other words the given subject travels from intersection 564 through intersection 561 to intersection 527.

Arrows show orientation of each line. Note that in case of the line 289 the subject travels in BACKWARDS direction and therefore the In_from value is NEGATIVE (-289) while in case of the line 234 the travelling is in FORWARD direction, so the In_from value is POSITIVE (234).
The category of this turn can be seen in the cat column and the value is 1817 (this kind of category is stored in tlayer). This category value belongs only to the lines with unique category values 234 and 289 (stored in tuclayer).

In the angle column for this record the value is -1.373597 radians which is roughly -80°. This perfectly makes sense since left turns have negative values and right turns have positive. The angle is measured as deviance from straight direction (which is 0°).

== Modules working with turntable ==

* {{cmd|v.net}} - creates the turntable
* {{cmd|v.net.path}}
* {{cmd|v.net.alloc}}
* {{cmd|v.net.iso}}
* {{cmd|v.net.salesman}}

=== Specific parameters of modules working with turntable ===

* '''arc_layer''' - Name or number of the arc layer that will be expanded by turntable.

* ''' turn_layer''' - Name or number of the layer to which the turntable will be attached.

* ''' turn_cat_layer''' - Name or number of the layer with unique categories for every line and point. The points are placed on every node.

==WxGUI Vector Network Analysis Tool (not yet implemented)==

In GUI for v.net modules there is the checkbox option to “use turns”. If checked, it is required to fill these additional parameters: tlayer (layer with turntable), tuclayer (layer with unique categories for turntable). The dialog is shown below.

[[Image:Params_ttb.png|center|400px|thumb]]

It is possible to predefine costs for default or custom angle intervals in the Global settings dialog as shown in picture below.

[[Image:Global_ttb.png|center|400px|thumb]]

The angle, however, is only the simple one between two straight lines (from previous intersection to current node and from current intersection to the next one ignoring any original shorter polyline segments).
After the turntable is created, it is possible to customize costs explicitly for any specific turn on any given intersection (node) via the Local settings dialog.

[[Image:Local_ttb.png|center|400px|thumb]]

==Further Reading==

[ftp://ftp.geoinfo.tuwien.ac.at/winter/winter02modeling.pdf Modeling Costs of Turns in Route Planning]

[[Category:Documentation]]
[[Category:Vector]]
[[Category:Network Analysis]]

Turns in the vector network analysis

2020-06-09T23:45:16Z

⚠️Turek:

__TOC__

The turntable can be created by {{cmd|v.net}} module, which is one of [[vector network analysis]] modules.
Building the turntable allows you to model e.g. traffic code, where some turns may be prohibited.
It creates a turntable with the costs for every possible turn on every possible node (intersection, crossroad) in given layer. U-turns are taken in account too.

[[Image:Line_graph.png|center|400px|thumb| Author: Stephan Winter]]

For better handling, a linegraph is created. In this linegraph, every line is represented by two nodes. These nodes have positive and negative values respectively, with their absolute values identical. Every node corresponds to opposite line direction. The positive node matches the direction of line. The negative node matches the opposite direction. For better understanding, let's have a travelling subject standing on a line (road) before an intersection wanting to cross it. This line's direction is TOWARDS the intersection. Travelling from this line through the intersection means that the subject is currently standing on the POSITIVE node representation of the line. After crossing to this line from any permitted direction, the subject gets to the NEGATIVE point representation of the line.

These two nodes (corresponding to the same line) are connected with two U-turns (for both directions). Every U-turn direction belongs to another intersection. U-turn from the POSITIVE node to the NEGATIVE one belongs to the intersection we are going to cross. The other U-turn belongs to the intersection at the opposite end of this line.

'''If features in analyzed network are changed, the turntable must be created again (e.g. it includes v.net connect operation). '''

==Turntable description==

Every record in the turntable represents one turn.

'''Columns description:'''

* '''cat''' – category in '''tlayer''' (layer with turntable), which corresponds to both lines in turn

* '''ln_from''' – unique category in '''tuclayer''' layer assigned to the starting line of the turn

* '''ln_to''' – unique category in '''tuclayer''' layer assigned to the ending line line of the turn

* '''cost''' – cost for turn (integer or double), assign -1 to close the turn

* '''isec''' – point category in '''tulayer''' layer, which represents the intersection, where the turn belongs

* '''angle''' – angle between the lines before and after the intersection (radians), positive -> turn to the right, negative -> turn to the left, 0 -> straight

[[Image:Turntable.png|center|800px|thumb]]

Every possible turn on any possible intersection is represented by unique record (line).
In the picture above you can see the turntable and part of vector layer with highlighted turn from the line with unique category 289 through the node (intersection) 561 to the line with unique category 234. In other words the given subject travels from intersection 564 through intersection 561 to intersection 527.

Arrows show orientation of each line. Note that in case of the line 289 the subject travels in BACKWARDS direction and therefore the In_from value is NEGATIVE (-289) while in case of the line 234 the travelling is in FORWARD direction, so the In_from value is POSITIVE (234).
The category of this turn can be seen in the cat column and the value is 1817 (this kind of category is stored in tlayer). This category value belongs only to the lines with unique category values 234 and 289 (stored in tuclayer).

In the angle column for this record the value is -1.373597 radians which is roughly -80°. This perfectly makes sense since left turns have negative values and right turns have positive. The angle is measured as deviance from straight direction (which is 0°).

== Modules working with turntable ==

* {{cmd|v.net}} - creates the turntable
* {{cmd|v.net.path}}
* {{cmd|v.net.alloc}}
* {{cmd|v.net.iso}}
* {{cmd|v.net.salesman}}

=== Specific parameters of modules working with turntable ===

* '''arclayer''' - Name or number of the arc layer that will be expanded by turntable.

* ''' turn_layer''' - Name or number of the layer to which the turntable will be attached.

* ''' turn_cat_layer''' - Name or number of the layer with unique categories for every line and point. The points are placed on every node.

==WxGUI Vector Network Analysis Tool (not yet implemented)==

In GUI for v.net modules there is the checkbox option to “use turns”. If checked, it is required to fill these additional parameters: tlayer (layer with turntable), tuclayer (layer with unique categories for turntable). The dialog is shown below.

[[Image:Params_ttb.png|center|400px|thumb]]

It is possible to predefine costs for default or custom angle intervals in the Global settings dialog as shown in picture below.

[[Image:Global_ttb.png|center|400px|thumb]]

The angle, however, is only the simple one between two straight lines (from previous intersection to current node and from current intersection to the next one ignoring any original shorter polyline segments).
After the turntable is created, it is possible to customize costs explicitly for any specific turn on any given intersection (node) via the Local settings dialog.

[[Image:Local_ttb.png|center|400px|thumb]]

==Further Reading==

[ftp://ftp.geoinfo.tuwien.ac.at/winter/winter02modeling.pdf Modeling Costs of Turns in Route Planning]

[[Category:Documentation]]
[[Category:Vector]]
[[Category:Network Analysis]]

GRASS GIS ISPRS Prague meetup 2016

2016-07-11T15:25:53Z

⚠️Turek: /* People */

People contributing or interested in contributing to GRASS GIS are welcome to meet during [http://www.isprs2016-prague.com/ ISPRS Congress] held in Prague 12-19th July 2016, Czech Republic (see also [[ISPRS XXIII Congress 2016: GRASS related workshops and presentations|presentations related to GRASS GIS]]).

Details about the meetings will be published later or during the congress.

Contact person: [[User:Landa|Martin Landa]] (landa.martin gmail com)

== Meetings ==

We are doing more than one meeting to discuss everything from GSoC to general visions.

=== Tuesday July 12 ===

When: evening

Where:

Topics:
* GSoC
** vector legend implementation

== People ==

Are you going to ISPRS Congress, or you are just in Prague and willing to meet? Please put your name to the table bellow.

{| class="wikitable sortable" border="2" cellspacing="0" cellpadding="4" rules="all" style="margin:1em 1em 1em 0; border:solid 1px #AAAAAA; border-collapse:collapse; background-color:#edf9c7; font-size:95%; empty-cells:show;"
|-
! No
! Participant
! Arrival
! Departure
! Country
! ISPRS participation
! Note
|-
| 1
| Martin Landa
| 12/7
| 19/7
| CZ
| yes
| Contact person
|-
| 2
| Helena Mitasova
| 15/7
| 19/7
| US
| yes
|
|-
| 3
| Vaclav Petras
| 12/7
| 19/7
| US
| yes
|
|-
| 4
| Anna Petrasova
| 12/7
| 19/7
| US
| yes
|
|-
| 5
| Yasuharu Yamada
| 16/7
| 18/7
| JP
| yes
|
|-
| 6
| Adam Laza
| 12/7
| 19/7
| CZ
| no
|
|-
| 7
| Ondrej Pesek
| 12/7
| 19/7
| CZ
| no
|
|-
| 8
| Stepan Turek
| 12/7
| 16/7
| CZ
| no
| just evenings after work
|-
|-
| 9
| Zofie Cimburova
| 14/7
| 18/7 or 19/7
| CZ
| no
|
|-
| 10
| Brendan Harmon
| 12/7
| 19/7
| US
| yes
|
|-}

[[Category: Workshops]]
[[Category: Code Sprint]]
[[Category: 2016]]

GRASS GIS ISPRS Prague meetup 2016

2016-07-02T18:39:54Z

⚠️Turek: /* People */

People contributing or interested in contributing to GRASS GIS are welcome to meet during [http://www.isprs2016-prague.com/ ISPRS Congress] held in Prague 12-19th July 2016, Czech Republic.

Details will be published later or during the congress.

Contact person: [[User:Landa|Martin Landa]] (landa.martin gmail com)

== People ==

Are you going to ISPRS Congress, or you are just in Prague and willing to meet? Please put your name to the table bellow.

{| class="wikitable sortable" border="2" cellspacing="0" cellpadding="4" rules="all" style="margin:1em 1em 1em 0; border:solid 1px #AAAAAA; border-collapse:collapse; background-color:#edf9c7; font-size:95%; empty-cells:show;"
|-
! No
! Participant
! Arrival
! Departure
! Country
! ISPRS participation
! Note
|-
| 1
| Martin Landa
| 12/7
| 19/7
| CZ
| yes
| Contact person
|-
| 2
| Helena Mitasova
| 15/7
| 19/7
| US
| yes
|
|-
| 3
| Vaclav Petras
| 12/7
| 19/7
| US
| yes
|
|-
| 4
| Anna Petrasova
| 12/7
| 19/7
| US
| yes
|
|-
| 5
| Yasuharu Yamada
| 16/7
| 18/7
| JP
| yes
|
|-
| 6
| Adam Laza
| 12/7
| 19/7
| CZ
| no
|
|-
| 7
| Ondrej Pesek
| 12/7
| 19/7
| CZ
| no
|
|-
| 8
| Stepan Turek
| 12/7
| 15/7 or 19/7
| CZ
| no
|
|-}

[[Category: Workshops]]
[[Category: Code Sprint]]
[[Category: 2016]]

OpenStreetMap

2016-03-06T21:44:37Z

⚠️Turek: /* Expample */

OSM Homepage: http://www.openstreetmap.org/

__TOC__

== Import ==

* [[GRASS_AddOns#v.in.osm]] (fairly rough script)

Conversion with {{wikipedia|Mapnik}} to raster tiles may work, but be very careful about projection issues, typical online web map tiles are not appropriate for GIS import.

=== Data as shapefiles ===

Get data from here:
* http://download.geofabrik.de/osm/ ,or
* http://downloads.cloudmade.com/

Then import with {{cmd|v.in.ogr}}

=== Data from WMS ===

* Web Map Service (WMS) for Europe: [http://mapbender.wheregroup.com/cgi-bin/mapserv?map=/data/umn/osm/osm_basic.map&VERSION=1.1.1&REQUEST=GetCapabilities&SERVICE=WMS GetCapabilities] to access the WMS
* No free/open world-wide server known - Badly needed

Then import with {{cmd|r.in.wms}}

=OSM vs. GRASS topology=

OSM topological model is different to GRASS topological model. OSM topologically correct connections of the lines can be on all nodes of the line. Unlike OSM, GRASS allows to connect lines only on their starting/end nodes.Therefore after the import it is needed to split lines into the smallest segments by "v.split vertices=2". However after application of the v.split, there are too many lines and some of them are not necessary. Module {{cmd|version=71|v.build.polylines}} cats=same merges the extra lines into single polyline.

Corect topological model is necessary e.g. to perform [[Vector network analysis]].

==Expample==

The following image represents roundabout after the import of the OSM shapefile from geofabrik. You can see that there is only one category number 917. It means that the roundabout circle is just one line and grass does not see all connections to the other lines, because they are not on the starting/end node of the circle.

[[Image:01 roundabout before.png‎|center|700px|thumb|v.in.ogr output]]

After the application of v.split it gives too many one segment lines. It is clear form the following image:

[[Image:02 roundabout split.png‎|center|700px|thumb|v.split output]]

{{cmd|version=71|v.build.polylines}} merges unnecessary segments. All lines starts/ends on the intersections with other lines as can be seen on the following image:

[[Image:03 roundabout after.png|center|700px|thumb|v.build.polylines output]]

There is another possibility to use {{cmd|version=71|v.clean}} tool=break but if there is e.g. a bridge then v.clean connects it to the roads going bellow it which is incorrect. The above described approach does not split the bridge there. See the difference on the following images:

[[Image:Vclean difference.png|center|700px|thumb|Output of v.split -> v.build.polylines]]
[[Image:Vclean.png|center|700px|thumb|Output of v.clean tool=break]]

=== See also ===

* [[Extrude 2D polygons to 3D]]
* [http://wiki.openstreetmap.org/wiki/Simplifying_OSM_Shapefiles_using_GRASS Simplifying OSM Shapefiles using GRASS]

[[Category: Geodata]]

OpenStreetMap

2016-03-06T21:43:31Z

⚠️Turek:

OSM Homepage: http://www.openstreetmap.org/

__TOC__

== Import ==

* [[GRASS_AddOns#v.in.osm]] (fairly rough script)

Conversion with {{wikipedia|Mapnik}} to raster tiles may work, but be very careful about projection issues, typical online web map tiles are not appropriate for GIS import.

=== Data as shapefiles ===

Get data from here:
* http://download.geofabrik.de/osm/ ,or
* http://downloads.cloudmade.com/

Then import with {{cmd|v.in.ogr}}

=== Data from WMS ===

* Web Map Service (WMS) for Europe: [http://mapbender.wheregroup.com/cgi-bin/mapserv?map=/data/umn/osm/osm_basic.map&VERSION=1.1.1&REQUEST=GetCapabilities&SERVICE=WMS GetCapabilities] to access the WMS
* No free/open world-wide server known - Badly needed

Then import with {{cmd|r.in.wms}}

=OSM vs. GRASS topology=

OSM topological model is different to GRASS topological model. OSM topologically correct connections of the lines can be on all nodes of the line. Unlike OSM, GRASS allows to connect lines only on their starting/end nodes.Therefore after the import it is needed to split lines into the smallest segments by "v.split vertices=2". However after application of the v.split, there are too many lines and some of them are not necessary. Module {{cmd|version=71|v.build.polylines}} cats=same merges the extra lines into single polyline.

Corect topological model is necessary e.g. to perform [[Vector network analysis]].

==Expample==

The following image represents roundabout after the import of the OSM shapefile from geofabrik. You can see that there is only one category number 917. It means that the roundabout circle is just one line and grass does not see all connections to the other lines, because they are not on the starting/end node of the circle.

[[Image:01 roundabout before.png‎|center|700px|thumb|v.in.ogr output]]

After the application of v.split it gives too many one segment lines. It is clear form the following image:

[[Image:02 roundabout split.png‎|center|700px|thumb|v.split output]]

{{cmd|version=71|v.build.polylines}} merges unnecessary segments. All lines starts/ends on the intersections with other lines as can be seen on the following image:

[[Image:03 roundabout after.png|center|700px|thumb|v.build.polylines output]]

There is another possibility to use {{cmd|version=71|v.clean}} tool=break but if you have e.g. bridge then v.clean connects it to the roads going bellow it which is incorrect. The above described approach does not split the bridge there. See the difference on the following images:

[[Image:Vclean difference.png|center|700px|thumb|Output of v.split -> v.build.polylines]]
[[Image:Vclean.png|center|700px|thumb|Output of v.clean tool=break]]

=== See also ===

* [[Extrude 2D polygons to 3D]]
* [http://wiki.openstreetmap.org/wiki/Simplifying_OSM_Shapefiles_using_GRASS Simplifying OSM Shapefiles using GRASS]

[[Category: Geodata]]

OpenStreetMap

2016-03-06T21:41:32Z

⚠️Turek: /* OSM vs. GRASS topology */

OSM Homepage: http://www.openstreetmap.org/

__TOC__

== Import ==

* [[GRASS_AddOns#v.in.osm]] (fairly rough script)

Conversion with {{wikipedia|Mapnik}} to raster tiles may work, but be very careful about projection issues, typical online web map tiles are not appropriate for GIS import.

=== Data as shapefiles ===

Get data from here:
* http://download.geofabrik.de/osm/ ,or
* http://downloads.cloudmade.com/

Then import with {{cmd|v.in.ogr}}

=== Data from WMS ===

* Web Map Service (WMS) for Europe: [http://mapbender.wheregroup.com/cgi-bin/mapserv?map=/data/umn/osm/osm_basic.map&VERSION=1.1.1&REQUEST=GetCapabilities&SERVICE=WMS GetCapabilities] to access the WMS
* No free/open world-wide server known - Badly needed

Then import with {{cmd|r.in.wms}}

=OSM vs. GRASS topology=

OSM topological model is different to GRASS topological model. OSM topologically correct connections of the lines can be on all nodes of the line. Unlike OSM, GRASS allows to connect lines only on their starting/end nodes.Therefore after the import it is needed to split lines into the smallest segments by "v.split vertices=2". However after application of the v.split, there are too many lines and some of them are not necessary. Module {{cmd|version=71|v.build.polylines}} cats=same merges the extra lines into single polyline.

Corect topological model is necessary e.g. to perform [[Vector network analysis]].

==Expample==

The following image represents roundabout after the import of the OSM shapefile from geofabrik. You can see that there is only one category number 917, it means that the roundabout circle is just one line and grass does not see all connections to the other lines, because they are not on the starting/end node of the circle.

[[Image:01 roundabout before.png‎|center|700px|thumb|v.in.ogr output]]

After the application of v.split you get too many one segment lines. It is clear form the following image:

[[Image:02 roundabout split.png‎|center|700px|thumb|v.split output]]

{{cmd|version=71|v.build.polylines}} gives you what you need. All lines starts/ends on the intersections with other lines as can be seen on the following image:

[[Image:03 roundabout after.png|center|700px|thumb|v.build.polylines output]]

There is another possibility to use {{cmd|version=71|v.clean}} tool=break but if you have e.g. bridge then v.clean connects it to the roads going bellow it which is incorrect. The above described approach does not split the bridge there. See the difference on the following images:

[[Image:Vclean difference.png|center|700px|thumb|Output of v.split -> v.build.polylines]]
[[Image:Vclean.png|center|700px|thumb|Output of v.clean tool=break]]

=== See also ===

* [[Extrude 2D polygons to 3D]]
* [http://wiki.openstreetmap.org/wiki/Simplifying_OSM_Shapefiles_using_GRASS Simplifying OSM Shapefiles using GRASS]

[[Category: Geodata]]

OpenStreetMap

2016-03-06T21:38:18Z

⚠️Turek:

OSM Homepage: http://www.openstreetmap.org/

__TOC__

== Import ==

* [[GRASS_AddOns#v.in.osm]] (fairly rough script)

Conversion with {{wikipedia|Mapnik}} to raster tiles may work, but be very careful about projection issues, typical online web map tiles are not appropriate for GIS import.

=== Data as shapefiles ===

Get data from here:
* http://download.geofabrik.de/osm/ ,or
* http://downloads.cloudmade.com/

Then import with {{cmd|v.in.ogr}}

=== Data from WMS ===

* Web Map Service (WMS) for Europe: [http://mapbender.wheregroup.com/cgi-bin/mapserv?map=/data/umn/osm/osm_basic.map&VERSION=1.1.1&REQUEST=GetCapabilities&SERVICE=WMS GetCapabilities] to access the WMS
* No free/open world-wide server known - Badly needed

Then import with {{cmd|r.in.wms}}

=OSM vs. GRASS topology=

OSM topological model is different to GRASS topological model. OSM topologically correct connections of the lines can be on all nodes of the line. Unlike OSM, GRASS allows to connect lines only on their starting/end nodes.Therefore after the import it is needed to split lines into the smallest segments by "v.split vertices=2". However after application of the v.split, there are too many lines and some of them are not necessary. Module {{cmd|version=71|v.build.polylines}} cats=same merges the extra lines into single polyline.

Corect topological model is necessary to e.g. perfomr [[Vector network analysis]].

==Expample==

The following image represents roundabout after the import of the OSM shapefile from geofabrik. You can see that there is only one category number 917, it means that the roundabout circle is just one line and grass does not see all connections to the other lines, because they are not on the starting/end node of the circle.

[[Image:01 roundabout before.png‎|center|700px|thumb|v.in.ogr output]]

After the application of v.split you get too many one segment lines. It is clear form the following image:

[[Image:02 roundabout split.png‎|center|700px|thumb|v.split output]]

{{cmd|version=71|v.build.polylines}} gives you what you need. All lines starts/ends on the intersections with other lines as can be seen on the following image:

[[Image:03 roundabout after.png|center|700px|thumb|v.build.polylines output]]

There is another possibility to use {{cmd|version=71|v.clean}} tool=break but if you have e.g. bridge then v.clean connects it to the roads going bellow it which is incorrect. The above described approach does not split the bridge there. See the difference on the following images:

[[Image:Vclean difference.png|center|700px|thumb|Output of v.split -> v.build.polylines]]
[[Image:Vclean.png|center|700px|thumb|Output of v.clean tool=break]]

=== See also ===

* [[Extrude 2D polygons to 3D]]
* [http://wiki.openstreetmap.org/wiki/Simplifying_OSM_Shapefiles_using_GRASS Simplifying OSM Shapefiles using GRASS]

[[Category: Geodata]]

OpenStreetMap

2016-03-06T21:36:43Z

⚠️Turek: topology

OSM Homepage: http://www.openstreetmap.org/

=== Import ===

* [[GRASS_AddOns#v.in.osm]] (fairly rough script)

Conversion with {{wikipedia|Mapnik}} to raster tiles may work, but be very careful about projection issues, typical online web map tiles are not appropriate for GIS import.

=== Data as shapefiles ===

Get data from here:
* http://download.geofabrik.de/osm/ ,or
* http://downloads.cloudmade.com/

Then import with {{cmd|v.in.ogr}}

=== Data from WMS ===

* Web Map Service (WMS) for Europe: [http://mapbender.wheregroup.com/cgi-bin/mapserv?map=/data/umn/osm/osm_basic.map&VERSION=1.1.1&REQUEST=GetCapabilities&SERVICE=WMS GetCapabilities] to access the WMS
* No free/open world-wide server known - Badly needed

Then import with {{cmd|r.in.wms}}

=OSM vs. GRASS topology=

OSM topological model is different to GRASS topological model. OSM topologically correct connections of the lines can be on all nodes of the line. Unlike OSM, GRASS allows to connect lines only on their starting/end nodes.Therefore after the import it is needed to split lines into the smallest segments by "v.split vertices=2". However after application of the v.split, there are too many lines and some of them are not necessary. Module {{cmd|version=71|v.build.polylines}} cats=same merges the extra lines into single polyline.

Corect topological model is necessary to e.g. perfomr {{Vector network analysis}}.

==Expample==

The following image represents roundabout after the import of the OSM shapefile from geofabrik. You can see that there is only one category number 917, it means that the roundabout circle is just one line and grass does not see all connections to the other lines, because they are not on the starting/end node of the circle.

[[Image:01 roundabout before.png‎|center|700px|thumb|v.in.ogr output]]

After the application of v.split you get too many one segment lines. It is clear form the following image:

[[Image:02 roundabout split.png‎|center|700px|thumb|v.split output]]

{{cmd|version=71|v.build.polylines}} gives you what you need. All lines starts/ends on the intersections with other lines as can be seen on the following image:

[[Image:03 roundabout after.png|center|700px|thumb|v.build.polylines output]]

There is another possibility to use {{cmd|version=71|v.clean}} tool=break but if you have e.g. bridge then v.clean connects it to the roads going bellow it which is incorrect. The above described approach does not split the bridge there. See the difference on the following images:

[[Image:Vclean difference.png|center|700px|thumb|Output of v.split -> v.build.polylines]]
[[Image:Vclean.png|center|700px|thumb|Output of v.clean tool=break]]

=== See also ===

* [[Extrude 2D polygons to 3D]]
* [http://wiki.openstreetmap.org/wiki/Simplifying_OSM_Shapefiles_using_GRASS Simplifying OSM Shapefiles using GRASS]

[[Category: Geodata]]

OpenStreetMap

2016-03-06T21:32:26Z

⚠️Turek:

OSM Homepage: http://www.openstreetmap.org/

=== Import ===

* [[GRASS_AddOns#v.in.osm]] (fairly rough script)

Conversion with {{wikipedia|Mapnik}} to raster tiles may work, but be very careful about projection issues, typical online web map tiles are not appropriate for GIS import.

=== Data as shapefiles ===

Get data from here:
* http://download.geofabrik.de/osm/ ,or
* http://downloads.cloudmade.com/

Then import with {{cmd|v.in.ogr}}

=== Data from WMS ===

* Web Map Service (WMS) for Europe: [http://mapbender.wheregroup.com/cgi-bin/mapserv?map=/data/umn/osm/osm_basic.map&VERSION=1.1.1&REQUEST=GetCapabilities&SERVICE=WMS GetCapabilities] to access the WMS
* No free/open world-wide server known - Badly needed

Then import with {{cmd|r.in.wms}}

=OSM vs. GRASS topology=

OSM topological model is different to GRASS topological model. OSM topologically correct connections of the lines can be on all nodes of the line. Unlike OSM, GRASS allows to connect lines only on their starting/end nodes.Therefore after the import it is needed to split lines into the smallest segments by "v.split vertices=2". However after application of the v.split, there are too many lines and some of them are not necessary. Module {{cmd|version=71|v.build.polylines}} cats=same merges the extra lines into single polyline.

==Expample==

The following image represents roundabout after the import of the OSM shapefile from geofabrik. You can see that there is only one category number 917, it means that the roundabout circle is just one line and grass does not see all connections to the other lines, because they are not on the starting/end node of the circle.

[[Image:01 roundabout before.png‎|center|700px|thumb|v.in.ogr output]]

After the application of v.split you get too many one segment lines. It is clear form the following image:

[[Image:02 roundabout split.png‎|center|700px|thumb|v.split output]]

{{cmd|version=71|v.build.polylines}} gives you what you need. All lines starts/ends on the intersections with other lines as can be seen on the following image:

[[Image:03 roundabout after.png|center|700px|thumb|v.build.polylines output]]

There is another possibility to use {{cmd|version=71|v.clean}} tool=break but if you have e.g. bridge then v.clean connects it to the roads going bellow it which is incorrect. The above described approach does not split the bridge there. See the difference on the following images:

[[Image:Vclean difference.png|center|700px|thumb|Output of v.split -> v.build.polylines]]
[[Image:Vclean.png|center|700px|thumb|Output of v.clean tool=break]]

=== See also ===

* [[Extrude 2D polygons to 3D]]
* [http://wiki.openstreetmap.org/wiki/Simplifying_OSM_Shapefiles_using_GRASS Simplifying OSM Shapefiles using GRASS]

[[Category: Geodata]]

OpenStreetMap

2016-03-06T21:28:54Z

⚠️Turek: /* Expample */

OSM Homepage: http://www.openstreetmap.org/

=== Import ===

* [[GRASS_AddOns#v.in.osm]] (fairly rough script)

Conversion with {{wikipedia|Mapnik}} to raster tiles may work, but be very careful about projection issues, typical online web map tiles are not appropriate for GIS import.

=== Data as shapefiles ===

Get data from here:
* http://download.geofabrik.de/osm/ ,or
* http://downloads.cloudmade.com/

Then import with {{cmd|v.in.ogr}}

=== Data from WMS ===

* Web Map Service (WMS) for Europe: [http://mapbender.wheregroup.com/cgi-bin/mapserv?map=/data/umn/osm/osm_basic.map&VERSION=1.1.1&REQUEST=GetCapabilities&SERVICE=WMS GetCapabilities] to access the WMS
* No free/open world-wide server known - Badly needed

Then import with {{cmd|r.in.wms}}

=OSM vs. GRASS topology=

OSM topological model is different to GRASS topological model. OSM topologically correct connections of the lines can be on all nodes of the line. Unlike OSM, GRASS allows to connect lines only on their starting/end nodes.Therefore after the import it is needed to split lines into the smallest segments by "v.split vertices=2". However after application of the v.split, there are too many lines and some of them are not necessary. Module {{cmd|version=71|v.build.polylines}} cats=same merges the extra lines into single polyline.

==Expample==

The roundabout_before.png image represents roundabout after the import of the OSM shapefile from geofabrik. You can see that there is only one category number 917, it means that the roundabout circle is just one segment and grass does not see all connections to other lines, because they are not on the starting/end node of the circle.

[[Image:01 roundabout before.png‎|center|700px|thumb|v.in.ogr output]]

After the application of v.split you get too many one segment lines. It is clear form roundabout_split.png.

[[Image:02 roundabout split.png‎|center|700px|thumb|v.split output]]

{{cmd|version=71|v.build.polylines}} gives you what you need. All lines starts/ends on the intersections with other lines.

[[Image:03 roundabout after.png|center|700px|thumb|v.build.polylines output]]

There is another possibility to use {{cmd|version=71|v.clean}} tool=break but if you have e. g. bridge then v.clean connects it to the roads going bellow it which is incorrect. The above described approach does not split the bridge there. See vclean,png and vclean_difference.png.

[[Image:Vclean difference.png|center|700px|thumb|Output of v.split -> v.build.polylines]]
[[Image:Vclean.png|center|700px|thumb|Output of v.clean tool=break]]

=== See also ===

* [[Extrude 2D polygons to 3D]]
* [http://wiki.openstreetmap.org/wiki/Simplifying_OSM_Shapefiles_using_GRASS Simplifying OSM Shapefiles using GRASS]

[[Category: Geodata]]

OpenStreetMap

2016-03-06T21:27:24Z

⚠️Turek: int tOSM vs. GRASS topology

OSM Homepage: http://www.openstreetmap.org/

=== Import ===

* [[GRASS_AddOns#v.in.osm]] (fairly rough script)

Conversion with {{wikipedia|Mapnik}} to raster tiles may work, but be very careful about projection issues, typical online web map tiles are not appropriate for GIS import.

=== Data as shapefiles ===

Get data from here:
* http://download.geofabrik.de/osm/ ,or
* http://downloads.cloudmade.com/

Then import with {{cmd|v.in.ogr}}

=== Data from WMS ===

* Web Map Service (WMS) for Europe: [http://mapbender.wheregroup.com/cgi-bin/mapserv?map=/data/umn/osm/osm_basic.map&VERSION=1.1.1&REQUEST=GetCapabilities&SERVICE=WMS GetCapabilities] to access the WMS
* No free/open world-wide server known - Badly needed

Then import with {{cmd|r.in.wms}}

=OSM vs. GRASS topology=

OSM topological model is different to GRASS topological model. OSM topologically correct connections of the lines can be on all nodes of the line. Unlike OSM, GRASS allows to connect lines only on their starting/end nodes.Therefore after the import it is needed to split lines into the smallest segments by "v.split vertices=2". However after application of the v.split, there are too many lines and some of them are not necessary. Module {{cmd|version=71|v.build.polylines}} cats=same merges the extra lines into single polyline.

==Expample==

The roundabout_before.png image represents roundabout after the import of the OSM shapefile from geofabrik. You can see that there is only one category number 917, it means that the roundabout circle is just one segment and grass does not see all connections to other lines, because they are not on the starting/end node of the circle.

[[Image:01 roundabout before.png‎|left|700px|thumb|v.in.ogr output]]

After the application of v.split you get too many one segment lines. It is clear form roundabout_split.png.

[[Image:02 roundabout split.png‎|left|700px|thumb|v.split output]]

{{cmd|version=71|v.build.polylines}} gives you what you need. All lines starts/ends on the intersections with other lines.

[[Image:03 roundabout after.png|left|700px|thumb|v.build.polylines output]]

There is another possibility to use {{cmd|version=71|v.clean}} tool=break but if you have e. g. bridge then v.clean connects it to the roads going bellow it which is incorrect. The above described approach does not split the bridge there. See vclean,png and vclean_difference.png.

[[Image:Vclean difference.png|left|700px|thumb|Output of v.split -> v.build.polylines]]
[[Image:Vclean.png|left|700px|thumb|Output of v.clean tool=break]]

=== See also ===

* [[Extrude 2D polygons to 3D]]
* [http://wiki.openstreetmap.org/wiki/Simplifying_OSM_Shapefiles_using_GRASS Simplifying OSM Shapefiles using GRASS]

[[Category: Geodata]]

OSM data

2016-03-06T21:02:51Z

⚠️Turek: Replaced content with "{{delete| moved to OpenStretMap }}"

File:03 roundabout after.png

2016-03-06T20:56:50Z

⚠️Turek:

File:02 roundabout split.png

2016-03-06T20:56:15Z

⚠️Turek:

File:01 roundabout before.png

2016-03-06T20:55:49Z

⚠️Turek:

File:Vclean.png

2016-03-06T20:54:48Z

⚠️Turek:

osm to grass conversion using use v.clean tool=break

File:Vclean.png

2016-03-06T20:53:36Z

⚠️Turek:

File:Vclean difference.png

2016-03-06T20:52:26Z

⚠️Turek:

OSM data

2016-03-02T21:44:11Z

⚠️Turek: init

=OSM vs. GRASS topology=

OSM topological model is different to GRASS topological model. OSM topologically correct connections of the lines can be on all nodes of the line. Unlike OSM, GRASS allows to connect lines only on their starting/end nodes.Therefore after the import it is needed to split lines into the smallest segments by "v.split vertices=2". However after application of the v.split, there are too many lines and some of them are not necessary. Module "v.build.polylines cats=same" merges the extra lines into single polyline.

==Expample==

The roundabout_before.png image represents roundabout after the import of the OSM shapefile from geofabrik. You can see that there is only one category number 917, it means that the roundabout circle is just one segment and grass does not see all connections to other lines, because they are not on the starting/end node of the circle.

After the application of v.split you get too many one segment lines. It is clear form roundabout_split.png.

v.polylines gives you what you need. All lines starts/ends on the intersections with other lines.

There is another possibility to use v.clean tool=break but if you have e. g. bridge then v.clean connects it to the roads going bellow it which is incorrect. The above described approach does not split the bridge there. See vclean,png and vclean_difference.png.

GRASS GIS contributors meetings in San Michele/February 2016

2016-02-23T18:18:18Z

⚠️Turek: /* Participants and reports */

=== Date ===

15-20 February 2016

=== Agenda ===

====Community stuff:====
* plan https://grasswiki.osgeo.org/wiki/Paris_Code_Sprint_2016_Agenda

====Time-based task:====

* Wed morning - GIS.lab (Markus, Luca, Ludka, Martin, ...)
* Fri morning - OSM data -> Vector network analysis with turntable (Markus, Luca, Stepan, ...)

====Raster:====
* discuss and ideally activate new raster compression scheme in "trunk" ({{trac|2750}})
** code: lib/raster/init.c, line 124
** Plan:
*** Null data are by default DEFLATE compressed: hence, if GRASS_COMPRESS_NULLS=1 or not defined at all. So, if the user sets GRASS_COMPRESS_NULLS to anything else than 1, Null data will not be compressed.
*** Note: Backward NULL file compression compatibility could be implemented in relbranch70 only by ZLIB's DEFLATE (see https://trac.osgeo.org/grass/ticket/2750#comment:36). Hence ZLIB may qualify for the default NULL compression algorithm.

====Projections:====

* issues postponed to [[Paris Code Sprint 2016 Agenda]]

====Core:====
* Kickstart of GRASS with LatLong predefined, open import wizard | switch projection

====QA:====
* integrate "coverity scan" with Travis, https://scan.coverity.com/travis_ci
* check "coverity scan": copy-paste errors, https://scan.coverity.com/projects/1038

====winGRASS:====
* install https://icl.cs.utk.edu/lapack-for-windows/ or https://www.scipy.org/scipylib/building/windows.html#blas-lapack-and-atlas

====Web CMS:====
* discuss CMS migration to Wordpress

====OSM data -> Vector network analysis with turntable====
* Add turntable support for OSM data
* discuss: How the whole solution should look like?
====Addons:====

* Update include/Make to reflect Addons with libs

=== Participants and reports ===

* Martin Landa
* Ludmila

* Matej

==== Luca ====
* closed tickets {{trac|2261}} {{trac|2319}} {{trac|2912}}
* started to work on {{trac|2294}}.... continue in [[GRASS Community Sprint Paris 2016|Paris]]

==== Markus ====

* Developed https://grasswiki.osgeo.org/wiki/Community_Sprint_Funding along with Martin and Luca
* checked {{trac|2916}} - Arch configure issue

==== Martin ====

* [https://trac.osgeo.org/grass/timeline?from=Feb+21%2C+2016&daysback=7&authors=martinl&milestone=on&ticket=on&changeset=on&wiki=on&update=Update Logs overview]

==== Stepan ====
* worked on modification of db library to allow proper work with 64bit integers (not yet commited needs discussion)
* created init version of v.in.osm module {{rev|67912}} by turek
* created draft (not yet commited) of v.db.category module to build category crosstable between two layers
* worked on worflow OSM data -> GRASS -> v.net.* analyses with turntable

=== Photos ===

[[Image:GRASS GIS contributors meetings in San Michele February 2016.jpg|400px]]

[[Category: Workshops]]
[[Category: Code Sprint]]
[[Category: 2016]]

GRASS GIS contributors meetings in San Michele/February 2016

2016-02-23T18:17:45Z

⚠️Turek: /* Stepan */

=== Date ===

15-20 February 2016

=== Agenda ===

====Community stuff:====
* plan https://grasswiki.osgeo.org/wiki/Paris_Code_Sprint_2016_Agenda

====Time-based task:====

* Wed morning - GIS.lab (Markus, Luca, Ludka, Martin, ...)
* Fri morning - OSM data -> Vector network analysis with turntable (Markus, Luca, Stepan, ...)

====Raster:====
* discuss and ideally activate new raster compression scheme in "trunk" ({{trac|2750}})
** code: lib/raster/init.c, line 124
** Plan:
*** Null data are by default DEFLATE compressed: hence, if GRASS_COMPRESS_NULLS=1 or not defined at all. So, if the user sets GRASS_COMPRESS_NULLS to anything else than 1, Null data will not be compressed.
*** Note: Backward NULL file compression compatibility could be implemented in relbranch70 only by ZLIB's DEFLATE (see https://trac.osgeo.org/grass/ticket/2750#comment:36). Hence ZLIB may qualify for the default NULL compression algorithm.

====Projections:====

* issues postponed to [[Paris Code Sprint 2016 Agenda]]

====Core:====
* Kickstart of GRASS with LatLong predefined, open import wizard | switch projection

====QA:====
* integrate "coverity scan" with Travis, https://scan.coverity.com/travis_ci
* check "coverity scan": copy-paste errors, https://scan.coverity.com/projects/1038

====winGRASS:====
* install https://icl.cs.utk.edu/lapack-for-windows/ or https://www.scipy.org/scipylib/building/windows.html#blas-lapack-and-atlas

====Web CMS:====
* discuss CMS migration to Wordpress

====OSM data -> Vector network analysis with turntable====
* Add turntable support for OSM data
* discuss: How the whole solution should look like?
====Addons:====

* Update include/Make to reflect Addons with libs

=== Participants and reports ===

* Martin Landa
* Ludmila

* Matej

==== Stepan ====
* worked on modification of db library to allow proper work with 64bit integers (not yet commited needs discussion)
* created init version of v.in.osm module {{rev|67912}} by turek
* created draft (not yet commited) of v.db.category module to build category crosstable between two layers
* worked on worflow OSM data -> GRASS -> v.net.* analyses with turntable

==== Luca ====
* closed tickets {{trac|2261}} {{trac|2319}} {{trac|2912}}
* started to work on {{trac|2294}}.... continue in [[GRASS Community Sprint Paris 2016|Paris]]

==== Markus ====

* Developed https://grasswiki.osgeo.org/wiki/Community_Sprint_Funding along with Martin and Luca
* checked {{trac|2916}} - Arch configure issue

==== Martin ====

* [https://trac.osgeo.org/grass/timeline?from=Feb+21%2C+2016&daysback=7&authors=martinl&milestone=on&ticket=on&changeset=on&wiki=on&update=Update Logs overview]

=== Photos ===

[[Image:GRASS GIS contributors meetings in San Michele February 2016.jpg|400px]]

[[Category: Workshops]]
[[Category: Code Sprint]]
[[Category: 2016]]

GRASS GIS contributors meetings in San Michele/February 2016

2016-02-23T18:17:15Z

⚠️Turek: /* Stepan */

=== Date ===

15-20 February 2016

=== Agenda ===

====Community stuff:====
* plan https://grasswiki.osgeo.org/wiki/Paris_Code_Sprint_2016_Agenda

====Time-based task:====

* Wed morning - GIS.lab (Markus, Luca, Ludka, Martin, ...)
* Fri morning - OSM data -> Vector network analysis with turntable (Markus, Luca, Stepan, ...)

====Raster:====
* discuss and ideally activate new raster compression scheme in "trunk" ({{trac|2750}})
** code: lib/raster/init.c, line 124
** Plan:
*** Null data are by default DEFLATE compressed: hence, if GRASS_COMPRESS_NULLS=1 or not defined at all. So, if the user sets GRASS_COMPRESS_NULLS to anything else than 1, Null data will not be compressed.
*** Note: Backward NULL file compression compatibility could be implemented in relbranch70 only by ZLIB's DEFLATE (see https://trac.osgeo.org/grass/ticket/2750#comment:36). Hence ZLIB may qualify for the default NULL compression algorithm.

====Projections:====

* issues postponed to [[Paris Code Sprint 2016 Agenda]]

====Core:====
* Kickstart of GRASS with LatLong predefined, open import wizard | switch projection

====QA:====
* integrate "coverity scan" with Travis, https://scan.coverity.com/travis_ci
* check "coverity scan": copy-paste errors, https://scan.coverity.com/projects/1038

====winGRASS:====
* install https://icl.cs.utk.edu/lapack-for-windows/ or https://www.scipy.org/scipylib/building/windows.html#blas-lapack-and-atlas

====Web CMS:====
* discuss CMS migration to Wordpress

====OSM data -> Vector network analysis with turntable====
* Add turntable support for OSM data
* discuss: How the whole solution should look like?
====Addons:====

* Update include/Make to reflect Addons with libs

=== Participants and reports ===

* Martin Landa
* Ludmila

* Matej

==== Stepan ====
* worked on modification of db library to allow proper work with 64bit integers (not yet commited needs discussion)
* created init version of v.in.osm module {{rev|r67912}} by turek
* created draft (not yet commited) of v.db.category module to build category crosstable between two layers
* worked on worflow OSM data -> GRASS -> v.net.* analyses with turntable

==== Luca ====
* closed tickets {{trac|2261}} {{trac|2319}} {{trac|2912}}
* started to work on {{trac|2294}}.... continue in [[GRASS Community Sprint Paris 2016|Paris]]

==== Markus ====

* Developed https://grasswiki.osgeo.org/wiki/Community_Sprint_Funding along with Martin and Luca
* checked {{trac|2916}} - Arch configure issue

==== Martin ====

* [https://trac.osgeo.org/grass/timeline?from=Feb+21%2C+2016&daysback=7&authors=martinl&milestone=on&ticket=on&changeset=on&wiki=on&update=Update Logs overview]

=== Photos ===

[[Image:GRASS GIS contributors meetings in San Michele February 2016.jpg|400px]]

[[Category: Workshops]]
[[Category: Code Sprint]]
[[Category: 2016]]

GRASS GIS contributors meetings in San Michele/February 2016

2016-02-23T18:15:44Z

⚠️Turek: +stepan

=== Date ===

15-20 February 2016

=== Agenda ===

====Community stuff:====
* plan https://grasswiki.osgeo.org/wiki/Paris_Code_Sprint_2016_Agenda

====Time-based task:====

* Wed morning - GIS.lab (Markus, Luca, Ludka, Martin, ...)
* Fri morning - OSM data -> Vector network analysis with turntable (Markus, Luca, Stepan, ...)

====Raster:====
* discuss and ideally activate new raster compression scheme in "trunk" ({{trac|2750}})
** code: lib/raster/init.c, line 124
** Plan:
*** Null data are by default DEFLATE compressed: hence, if GRASS_COMPRESS_NULLS=1 or not defined at all. So, if the user sets GRASS_COMPRESS_NULLS to anything else than 1, Null data will not be compressed.
*** Note: Backward NULL file compression compatibility could be implemented in relbranch70 only by ZLIB's DEFLATE (see https://trac.osgeo.org/grass/ticket/2750#comment:36). Hence ZLIB may qualify for the default NULL compression algorithm.

====Projections:====

* issues postponed to [[Paris Code Sprint 2016 Agenda]]

====Core:====
* Kickstart of GRASS with LatLong predefined, open import wizard | switch projection

====QA:====
* integrate "coverity scan" with Travis, https://scan.coverity.com/travis_ci
* check "coverity scan": copy-paste errors, https://scan.coverity.com/projects/1038

====winGRASS:====
* install https://icl.cs.utk.edu/lapack-for-windows/ or https://www.scipy.org/scipylib/building/windows.html#blas-lapack-and-atlas

====Web CMS:====
* discuss CMS migration to Wordpress

====OSM data -> Vector network analysis with turntable====
* Add turntable support for OSM data
* discuss: How the whole solution should look like?
====Addons:====

* Update include/Make to reflect Addons with libs

=== Participants and reports ===

* Martin Landa
* Ludmila

* Matej

==== Stepan ====
* worked on modification of db library to allow proper work with 64bit integers (not yet commited needs discussion)
* created init version of v.in.osm module {{r67912}} by turek
* created draft (not yet commited) of v.db.category module to build category crosstable between two layers
* worked on worflow OSM data -> GRASS -> v.net.* analyses with turntable

==== Luca ====
* closed tickets {{trac|2261}} {{trac|2319}} {{trac|2912}}
* started to work on {{trac|2294}}.... continue in [[GRASS Community Sprint Paris 2016|Paris]]

==== Markus ====

* Developed https://grasswiki.osgeo.org/wiki/Community_Sprint_Funding along with Martin and Luca
* checked {{trac|2916}} - Arch configure issue

==== Martin ====

* [https://trac.osgeo.org/grass/timeline?from=Feb+21%2C+2016&daysback=7&authors=martinl&milestone=on&ticket=on&changeset=on&wiki=on&update=Update Logs overview]

=== Photos ===

[[Image:GRASS GIS contributors meetings in San Michele February 2016.jpg|400px]]

[[Category: Workshops]]
[[Category: Code Sprint]]
[[Category: 2016]]

GRASS GIS contributors meetings in San Michele/February 2016

2016-02-17T16:47:29Z

⚠️Turek: /* Time-based task: */

GRASS GIS contributors meetings in San Michele/February 2016

2016-02-16T15:16:33Z

⚠️Turek: caption style

GRASS GIS contributors meetings in San Michele/February 2016

2016-02-16T15:06:42Z

⚠️Turek: captions style

=== Date ===

15-20 February 2016

=== Agenda ===

Community stuff:
* plan https://grasswiki.osgeo.org/wiki/Paris_Code_Sprint_2016_Agenda

====Raster:====
* discuss and ideally activate new raster compression scheme in "trunk" ({{trac|2750}})
** code: lib/raster/init.c, line 124
** Plan:
*** Null data are by default DEFLATE compressed: hence, if GRASS_COMPRESS_NULLS=1 or not defined at all. So, if the user sets GRASS_COMPRESS_NULLS to anything else than 1, Null data will not be compressed.
*** Note: Backward NULL file compression compatibility could be implemented in relbranch70 only by ZLIB's DEFLATE (see https://trac.osgeo.org/grass/ticket/2750#comment:36). Hence ZLIB may qualify for the default NULL compression algorithm.

====Projections:====
* fix GDAL CSV: {{trac|2456}}
* EPSG: {{trac|2490}}
* revisit Even R's comments on this

====Core:====
* Kickstart of GRASS with LatLong predefined, open import wizard | switch projection

====QA:====
* integrate "coverity scan" with Travis, https://scan.coverity.com/travis_ci
* check "coverity scan": copy-paste errors, https://scan.coverity.com/projects/1038

====winGRASS:====
* install https://icl.cs.utk.edu/lapack-for-windows/ or https://www.scipy.org/scipylib/building/windows.html#blas-lapack-and-atlas

====Web CMS:====
* discuss CMS migration to Wordpress

====OSM data -> Vector network analysis with turntable====
* Add turntable support for OSM data
* discuss: How the whole solution should look like?
====Addons:====

* Update include/Make to reflect Addons with libs

=== Participants and reports ===

* Martin Landa
* Ludmila
* Stepan
* Matej
* Luca

==== Markus ====
* checked {{trac|2916}} - Arch configure issue

=== Photos ===

[[Category: Workshops]]
[[Category: Code Sprint]]

GRASS GIS contributors meetings in San Michele/February 2016

2016-02-16T15:05:13Z

⚠️Turek: /* Agenda */

=== Date ===

15-20 February 2016

=== Agenda ===

Community stuff:
* plan https://grasswiki.osgeo.org/wiki/Paris_Code_Sprint_2016_Agenda

Raster:
* discuss and ideally activate new raster compression scheme in "trunk" ({{trac|2750}})
** code: lib/raster/init.c, line 124
** Plan:
*** Null data are by default DEFLATE compressed: hence, if GRASS_COMPRESS_NULLS=1 or not defined at all. So, if the user sets GRASS_COMPRESS_NULLS to anything else than 1, Null data will not be compressed.
*** Note: Backward NULL file compression compatibility could be implemented in relbranch70 only by ZLIB's DEFLATE (see https://trac.osgeo.org/grass/ticket/2750#comment:36). Hence ZLIB may qualify for the default NULL compression algorithm.

Projections:
* fix GDAL CSV: {{trac|2456}}
* EPSG: {{trac|2490}}
* revisit Even R's comments on this

Core:
* Kickstart of GRASS with LatLong predefined, open import wizard | switch projection

QA:
* integrate "coverity scan" with Travis, https://scan.coverity.com/travis_ci
* check "coverity scan": copy-paste errors, https://scan.coverity.com/projects/1038

winGRASS:
* install https://icl.cs.utk.edu/lapack-for-windows/ or https://www.scipy.org/scipylib/building/windows.html#blas-lapack-and-atlas

Web CMS:
* discuss CMS migration to Wordpress

OSM data -> Vector network analysis with TURNTABLE
* Add turntable support for OSM data
* discuss: How the whole solution should look like?
Addons:

* Update include/Make to reflect Addons with libs

=== Participants and reports ===

* Martin Landa
* Ludmila
* Stepan
* Matej
* Luca

==== Markus ====
* checked {{trac|2916}} - Arch configure issue

=== Photos ===

[[Category: Workshops]]
[[Category: Code Sprint]]

GRASS GIS contributors meetings in San Michele/February 2016

2016-02-16T15:04:57Z

⚠️Turek: /* Agenda */

=== Date ===

15-20 February 2016

=== Agenda ===

Community stuff:
* plan https://grasswiki.osgeo.org/wiki/Paris_Code_Sprint_2016_Agenda

Raster:
* discuss and ideally activate new raster compression scheme in "trunk" ({{trac|2750}})
** code: lib/raster/init.c, line 124
** Plan:
*** Null data are by default DEFLATE compressed: hence, if GRASS_COMPRESS_NULLS=1 or not defined at all. So, if the user sets GRASS_COMPRESS_NULLS to anything else than 1, Null data will not be compressed.
*** Note: Backward NULL file compression compatibility could be implemented in relbranch70 only by ZLIB's DEFLATE (see https://trac.osgeo.org/grass/ticket/2750#comment:36). Hence ZLIB may qualify for the default NULL compression algorithm.

Projections:
* fix GDAL CSV: {{trac|2456}}
* EPSG: {{trac|2490}}
* revisit Even R's comments on this

Core:
* Kickstart of GRASS with LatLong predefined, open import wizard | switch projection

QA:
* integrate "coverity scan" with Travis, https://scan.coverity.com/travis_ci
* check "coverity scan": copy-paste errors, https://scan.coverity.com/projects/1038

winGRASS:
* install https://icl.cs.utk.edu/lapack-for-windows/ or https://www.scipy.org/scipylib/building/windows.html#blas-lapack-and-atlas

Web CMS:
* discuss CMS migration to Wordpress

OSM data -> Vector network analysis with TURNTABLE
* Add turntable support for OSM data
* discuss: How to whole solution should look like?
Addons:

* Update include/Make to reflect Addons with libs

=== Participants and reports ===

* Martin Landa
* Ludmila
* Stepan
* Matej
* Luca

==== Markus ====
* checked {{trac|2916}} - Arch configure issue

=== Photos ===

[[Category: Workshops]]
[[Category: Code Sprint]]

GRASS GIS contributors meetings in San Michele/February 2016

2016-02-15T08:19:00Z

⚠️Turek:

=== Date ===

15-20 February 2016

=== Participants ===

* Martin Landa
* Ludmila
* Stepan
* Matej
* Luca
* Markus

=== Agenda ===

Community stuff:
* plan https://grasswiki.osgeo.org/wiki/Paris_Code_Sprint_2016_Agenda

Raster:
* discuss and ideally activate new raster compression scheme in "trunk" ({{trac|2750}})

Projections:
* fix GDAL CSV: {{trac|2456}}
* EPSG: {{trac|2490}}

Core:
* Kickstart of GRASS with LatLong predefined, open import wizard | switch projection

QA:
* integrate "coverity scan" with Travis, https://scan.coverity.com/travis_ci
* check "coverity scan": copy-paste errors, https://scan.coverity.com/projects/1038

winGRASS:
* install https://icl.cs.utk.edu/lapack-for-windows/ or https://www.scipy.org/scipylib/building/windows.html#blas-lapack-and-atlas

Web CMS:
* discuss CMS migration to Wordpress

Vector network analysis

* Add turntable support for OSM data

=== Photos ===

[[Category: Workshops]]
[[Category: Code Sprint]]

GRASS GIS contributors meetings in San Michele/February 2016

2016-02-15T08:18:38Z

⚠️Turek: OSM turntable

=== Date ===

15-20 February 2016

=== Participants ===

* Martin Landa
* Ludmila
* Stepan
* Matej
* Luca
* Markus

=== Agenda ===

Community stuff:
* plan https://grasswiki.osgeo.org/wiki/Paris_Code_Sprint_2016_Agenda

Raster:
* discuss and ideally activate new raster compression scheme in "trunk" ({{trac|2750}})

Projections:
* fix GDAL CSV: {{trac|2456}}
* EPSG: {{trac|2490}}

Core:
* Kickstart of GRASS with LatLong predefined, open import wizard | switch projection

QA:
* integrate "coverity scan" with Travis, https://scan.coverity.com/travis_ci
* check "coverity scan": copy-paste errors, https://scan.coverity.com/projects/1038

winGRASS:
* install https://icl.cs.utk.edu/lapack-for-windows/ or https://www.scipy.org/scipylib/building/windows.html#blas-lapack-and-atlas

Web CMS:
* discuss CMS migration to Wordpress

Vector analysis

* Add turntable support for OSM data

=== Photos ===

[[Category: Workshops]]
[[Category: Code Sprint]]

GRASS GIS contributors meetings in Solany/February 2016

2016-02-07T10:17:04Z

⚠️Turek: + discussed topic

== 2. Meeting (January 5-7 2016) ==

=== Discussed topics ===

* {{trac|2888}}
* {{trac|2889}}
* v.kriging: enable BLAS and LAPACK for Windows
* upgrade wxPython in OSGeo4W to wxPython 3.0
* {{trac|2894}}
* db_rollback_transaction()
* Vect_rewrite_line, Vect_read_line - force topological level

=== Participants & reports ===

Note: maximum number of participants: 4-5 (due to winter time)

==== Martin Landa ====

* [https://trac.osgeo.org/grass/timeline?from=Feb+08%2C+2016&daysback=3&authors=martinl&milestone=on&ticket=on&changeset=on&wiki=on&update=Update SVN logs]

==== Stepan Turek ====

* worked mostly on importing data from osm to grass in form which allows to use the osm data for network vector analysis with turntable

* [https://trac.osgeo.org/grass/timeline?from=Feb+08%2C+2016&daysback=3&authors=turek&milestone=on&ticket=on&changeset=on&wiki=on&update=Update SVN logs]

==== Matej Krejci ====

* [https://trac.osgeo.org/grass/timeline?from=Feb+08%2C+2016&daysback=3&authors=krejcmat&milestone=on&ticket=on&changeset=on&wiki=on&update=Update SVN logs]

==== Ludmila Furtkevicova ====

* [https://trac.osgeo.org/grass/timeline?from=Feb+08%2C+2016&daysback=3&authors=lfurkevicova&milestone=on&ticket=on&changeset=on&wiki=on&update=Update SVN logs]

=== Photos ===

GRASS GIS contributors meetings in Solany/February 2016

2016-02-07T10:13:15Z

⚠️Turek: /* Stepan Turek */

== 2. Meeting (January 5-7 2016) ==

=== Discussed topics ===

* {{trac|2888}}
* {{trac|2889}}
* v.kriging: enable BLAS and LAPACK for Windows
* upgrade wxPython in OSGeo4W to wxPython 3.0
* {{trac|2894}}
* db_rollback_transaction()

=== Participants & reports ===

Note: maximum number of participants: 4-5 (due to winter time)

==== Martin Landa ====

* [https://trac.osgeo.org/grass/timeline?from=Feb+08%2C+2016&daysback=3&authors=martinl&milestone=on&ticket=on&changeset=on&wiki=on&update=Update SVN logs]

==== Stepan Turek ====

* worked mostly on importing data from osm to grass in form which allows to use the osm data for network vector analysis with turntable

* [https://trac.osgeo.org/grass/timeline?from=Feb+08%2C+2016&daysback=3&authors=turek&milestone=on&ticket=on&changeset=on&wiki=on&update=Update SVN logs]

==== Matej Krejci ====

* [https://trac.osgeo.org/grass/timeline?from=Feb+08%2C+2016&daysback=3&authors=krejcmat&milestone=on&ticket=on&changeset=on&wiki=on&update=Update SVN logs]

==== Ludmila Furtkevicova ====

* [https://trac.osgeo.org/grass/timeline?from=Feb+08%2C+2016&daysback=3&authors=lfurkevicova&milestone=on&ticket=on&changeset=on&wiki=on&update=Update SVN logs]

=== Photos ===

Turns in the vector network analysis

2014-11-28T10:23:48Z

⚠️Turek: info about grass version supporting turntable

__TOC__

The turntable (available in GRASS >= 7.1) can be created by {{cmd|v.net|version=71}} module, which is one of [[vector network analysis]] modules.
Building the turntable allows you to model e.g. trafic code, where some turns may be prohibited.
It creates a turntable with the costs for every possible turn on every possible node (intersection, crossroad) in given layer. U-turns are taken in account too.

[[Image:Line_graph.png|center|400px|thumb| Author: Stephan Winter]]

For better handling, a linegraph is created. In this linegraph, every line is represented by two nodes. These nodes have positive and negative values respectively, with their absolute values identical. Every node corresponds to opposite line direction. The positive node matches the direction of line. The negative node matches the opposite direction. For better understanding, let's have a travelling subject standing on a line (road) before an intersection wanting to cross it. This line's direction is TOWARDS the intersection. Travelling from this line through the intersection means that the subject is currently standing on the POSITIVE node representation of the line. After crossing to this line from any permitted direction, the subject gets to the NEGATIVE point representation of the line.

These two nodes (corresponding to the same line) are connected with two U-turns (for both directions). Every U-turn direction belongs to another intersection. U-turn from the POSITIVE node to the NEGATIVE one belongs to the intersection we are going to cross. The other U-turn belongs to the intersection at the opposite end of this line.

'''If features in analyzed network are changed, the turntable must be created again (e.g. it includes v.net connect operation). '''

==Turntable description==

Every record in the turntable represents one turn.

'''Columns description:'''

* '''cat''' – category in '''tlayer''' (layer with turntable), which corresponds to both lines in turn

* '''ln_from''' – unique category in '''tuclayer''' layer assigned to the starting line of the turn

* '''ln_to''' – unique category in '''tuclayer''' layer assigned to the ending line line of the turn

* '''cost''' – cost for turn (integer or double), assign -1 to close the turn

* '''isec''' – point category in '''tulayer''' layer, which represents the intersection, where the turn belongs

* '''angle''' – angle between the lines before and after the intersection (radians), positive -> turn to the right, negative -> turn to the left, 0 -> straight

[[Image:Turntable.png|center|800px|thumb]]

Every possible turn on any possible intersection is represented by unique record (line).
In the picture above you can see the turntable and part of vector layer with highlighted turn from the line with unique category 289 through the node (intersection) 561 to the line with unique category 234. In other words the given subject travels from intersection 564 through intersection 561 to intersection 527.

Arrows show orientation of each line. Note that in case of the line 289 the subject travels in BACKWARDS direction and therefore the In_from value is NEGATIVE (-289) while in case of the line 234 the travelling is in FORWARD direction, so the In_from value is POSITIVE (234).
The category of this turn can be seen in the cat column and the value is 1817 (this kind of category is stored in tlayer). This category value belongs only to the lines with unique category values 234 and 289 (stored in tuclayer).

In the angle column for this record the value is -1.373597 radians which is roughly -80°. This perfectly makes sense since left turns have negative values and right turns have positive. The angle is measured as deviance from straight direction (which is 0°).

== Modules working with turntable ==

* {{cmd|v.net|version=70}} - creates the turntable

* {{cmd|v.net.path|version=70}}

* {{cmd|v.net.alloc|version=70}}

* {{cmd|v.net.iso|version=70}}

* {{cmd|v.net.salesman|version=70}}
=== Specific parameters of modules working with turntable ===

* '''alayer''' - Name or number of the arc layer that will be expanded by turntable.

* '''tlayer''' - Name or number of the layer to which the turntable will be attached.

* '''tuclayer''' - Name or number of the layer with unique categories for every line and point. The points are placed on every node.

==WxGUI Vector Network Analysis Tool (not yet implemented)==

In GUI for v.net modules there is the checkbox option to “use turns”. If checked, it is required to fill these additional parameters: tlayer (layer with turntable), tuclayer (layer with unique categories for turntable). The dialog is shown below.

[[Image:Params_ttb.png|center|400px|thumb]]

It is possible to predefine costs for default or custom angle intervals in the Global settings dialog as shown in picture below.

[[Image:Global_ttb.png|center|400px|thumb]]

The angle, however, is only the simple one between two straight lines (from previous intersection to current node and from current intersection to the next one ignoring any original shorter polyline segments).
After the turntable is created, it is possible to customize costs explicitly for any specific turn on any given intersection (node) via the Local settings dialog.

[[Image:Local_ttb.png|center|400px|thumb]]

==Further Reading==

[ftp://ftp.geoinfo.tuwien.ac.at/winter/winter02modeling.pdf Modeling Costs of Turns in Route Planning]

[[Category:Documentation]]
[[Category:Vector]]
[[Category:Network Analysis]]

Turns in the vector network analysis

2014-11-28T10:20:58Z

⚠️Turek: turntable gui not implemented

{{ToModify}}

__TOC__

The turntable can be created by {{cmd|v.net|version=70}} module, which is one of [[vector network analysis]] modules.
Building the turntable allows you to model e.g. trafic code, where some turns may be prohibited.
It creates a turntable with the costs for every possible turn on every possible node (intersection, crossroad) in given layer. U-turns are taken in account too.

[[Image:Line_graph.png|center|400px|thumb| Author: Stephan Winter]]

For better handling, a linegraph is created. In this linegraph, every line is represented by two nodes. These nodes have positive and negative values respectively, with their absolute values identical. Every node corresponds to opposite line direction. The positive node matches the direction of line. The negative node matches the opposite direction. For better understanding, let's have a travelling subject standing on a line (road) before an intersection wanting to cross it. This line's direction is TOWARDS the intersection. Travelling from this line through the intersection means that the subject is currently standing on the POSITIVE node representation of the line. After crossing to this line from any permitted direction, the subject gets to the NEGATIVE point representation of the line.

These two nodes (corresponding to the same line) are connected with two U-turns (for both directions). Every U-turn direction belongs to another intersection. U-turn from the POSITIVE node to the NEGATIVE one belongs to the intersection we are going to cross. The other U-turn belongs to the intersection at the opposite end of this line.

'''If features in analyzed network are changed, the turntable must be created again (e.g. it includes v.net connect operation). '''

==Turntable description==

Every record in the turntable represents one turn.

'''Columns description:'''

* '''cat''' – category in '''tlayer''' (layer with turntable), which corresponds to both lines in turn

* '''ln_from''' – unique category in '''tuclayer''' layer assigned to the starting line of the turn

* '''ln_to''' – unique category in '''tuclayer''' layer assigned to the ending line line of the turn

* '''cost''' – cost for turn (integer or double), assign -1 to close the turn

* '''isec''' – point category in '''tulayer''' layer, which represents the intersection, where the turn belongs

* '''angle''' – angle between the lines before and after the intersection (radians), positive -> turn to the right, negative -> turn to the left, 0 -> straight

[[Image:Turntable.png|center|800px|thumb]]

Every possible turn on any possible intersection is represented by unique record (line).
In the picture above you can see the turntable and part of vector layer with highlighted turn from the line with unique category 289 through the node (intersection) 561 to the line with unique category 234. In other words the given subject travels from intersection 564 through intersection 561 to intersection 527.

Arrows show orientation of each line. Note that in case of the line 289 the subject travels in BACKWARDS direction and therefore the In_from value is NEGATIVE (-289) while in case of the line 234 the travelling is in FORWARD direction, so the In_from value is POSITIVE (234).
The category of this turn can be seen in the cat column and the value is 1817 (this kind of category is stored in tlayer). This category value belongs only to the lines with unique category values 234 and 289 (stored in tuclayer).

In the angle column for this record the value is -1.373597 radians which is roughly -80°. This perfectly makes sense since left turns have negative values and right turns have positive. The angle is measured as deviance from straight direction (which is 0°).

== Modules working with turntable ==

* {{cmd|v.net|version=70}} - creates the turntable

* {{cmd|v.net.path|version=70}}

* {{cmd|v.net.alloc|version=70}}

* {{cmd|v.net.iso|version=70}}

* {{cmd|v.net.salesman|version=70}}
=== Specific parameters of modules working with turntable ===

* '''alayer''' - Name or number of the arc layer that will be expanded by turntable.

* '''tlayer''' - Name or number of the layer to which the turntable will be attached.

* '''tuclayer''' - Name or number of the layer with unique categories for every line and point. The points are placed on every node.

==WxGUI Vector Network Analysis Tool (not yet implemented)==

In GUI for v.net modules there is the checkbox option to “use turns”. If checked, it is required to fill these additional parameters: tlayer (layer with turntable), tuclayer (layer with unique categories for turntable). The dialog is shown below.

[[Image:Params_ttb.png|center|400px|thumb]]

It is possible to predefine costs for default or custom angle intervals in the Global settings dialog as shown in picture below.

[[Image:Global_ttb.png|center|400px|thumb]]

The angle, however, is only the simple one between two straight lines (from previous intersection to current node and from current intersection to the next one ignoring any original shorter polyline segments).
After the turntable is created, it is possible to customize costs explicitly for any specific turn on any given intersection (node) via the Local settings dialog.

[[Image:Local_ttb.png|center|400px|thumb]]

==Further Reading==

[ftp://ftp.geoinfo.tuwien.ac.at/winter/winter02modeling.pdf Modeling Costs of Turns in Route Planning]

[[Category:Documentation]]
[[Category:Vector]]
[[Category:Network Analysis]]

Vector network analysis

2014-11-28T10:19:51Z

⚠️Turek: turntable

GRASS provides support for vector network analysis using the [http://trac.osgeo.org/grass/browser/grass/trunk/lib/vector/dglib/ DGlib] Directed Graph Library.

GRASS 7 has [[WxGUI Vector Network Analysis Tool]] front-end, which supports some of the vector network analysis modules.
__TOC__
== Implemented algorithms ==

The following algorithms are implemented (GRASS 6.5+):

* Vector maintenance: {{cmd|v.net|version=70}}
* Shortest path: {{cmd|d.path|version=64}} and {{cmd|v.net.path|version=70}}
* Shortest path between all pairs of nodes {{cmd|v.net.allpairs|version=70}}
* Allocation of sources (create subnetworks, e.g. police station zones): {{cmd|v.net.alloc|version=70}}
* Iso-distances (from centers): {{cmd|v.net.iso|version=70}}
* Computes bridges and articulation points: {{cmd|v.net.bridge|version=70}}
* Computes degree, centrality, betweeness, closeness and eigenvector centrality measures: {{cmd|v.net.centrality|version=70}}
* Computes strongly and weakly connected components: {{cmd|v.net.components|version=70}}
* Computes vertex connectivity between two sets of nodes: {{cmd|v.net.connectivity|version=70}}
* Computes shortest distance via the network between the given sets of features: {{cmd|v.net.distance|version=70}}
* Computes the maximum flow between two sets of nodes: {{cmd|v.net.flow|version=70}}
* Computes minimum spanning tree: {{cmd|v.net.spanningtree|version=70}}
* Minimum Steiner trees (star-like connections, e.g. broadband cable connections): {{cmd|v.net.steiner|version=70}}
* Finds shortest path using timetables: {{cmd|v.net.timetable|version=70}}
* Traveling salesman (round trip): {{cmd|v.net.salesman|version=70}}

Vector directions are defined by the digitizing direction (a-->--b). You can navigate either omnidirectionally or differently in each directions as both directions are supported. Network modules provide parameters to assign attribute columns to the forward and backward direction. To see how a vector is directed, use the "display" parameter of {{cmd|d.vect}} (set display=dir).
Use [[Turntable]] to assign costs to turns on the network.

* see the {{cmd|vectorintro|desc=vector map processing and network analysis}} help page

== Example: Shortest path routing ==

* see the {{cmd|v.net.path}} and {{cmd|d.path}} help pages

== Common parameters ==

* '''input''' - This is the name of input vector map or data source for direct OGR access.

* '''output''' - This is the name for output vector map.

* '''type''' - This parameter defines arc type, which can be line or boundary.

* '''alayer''' - This parameter is a number and defines the arc layer. Vector features can have category values in different layers. This number determines which layer to use. When used with direct OGR access this is the layer name.

* '''nlayer''' - This parameter is a number and defines the node layer. Vector features can have category values in different layers. This number determines which layer to use. When used with direct OGR access this is the layer name.

* '''afcolumn''' - This is name of the cost column for moving in forward direction or forward and backward directions together.

* '''abcolumn''' - This is name of the cost column for moving in backward direction.

* '''ncolumn''' - This is name of the cost column for moving through nodes.

If you are not familiar with layers concept in GRASS see [[Vector Database Management]].

== New ideas ==

* [[Vector network analysis ideas]] (please help to realize)

== Screenshots ==
* more screenshots [http://grass.osgeo.org/screenshots/vector.php from the GRASS website]

[[Image:wxgui-vnet-alloc.png|center|600px|thumb|Subsets for nearest centers (v.net.alloc)]]

=== Old GRASS 5 screenshots ===

<center>
{|
| [[Image:V.net.iso.png|center|400px|thumb|{{cmd|v.net.iso}} - Split net to bands between cost isolines (direction from centre). Costs of centre node are used in calculation.]]
|[[Image:V.net.alloc.png|center|400px|thumb|{{cmd|v.net.alloc}} - Allocates subnets for nearest centres (direction from centre). Costs of centre node are used in calculation.]]
|-
|[[Image:D.path.jpg|center|400px|thumb|{{cmd|d.path}} - Find shortest path for selected starting and ending node.]]
| 
|}
</center>

== See also ==

* [[Turntable]]
* [[GSoC Network Analysis]]: many new modules!

== Tutorials ==

* [http://www.ing.unitn.it/~grass/docs/tutorial_64_en/htdocs/esercitazione/network_analysis/index.html Network analysis tutorial] by University of Trento, Italy

== External links ==

* [http://www.ossgis.co.cc/2009/01/grass-gis-network-analysis-subnets.html GRASS GIS: Network Analysis (Subnets within a vector network)]

[[Category:Documentation]]
[[Category:Vector]]
[[Category:Network Analysis]]

Talk:GRASS Community Sprint Vienna 2014

2014-03-28T11:10:46Z

⚠️Turek: /* Stepan Turek */

== Reports ==
<center>
[[File:Vienna2014 code sprint panorama tiny.jpg]]<br>
... way more than 50 participants present!
</center>

=== *** NEWS *** ===

First beta release of GRASS GIS 7.0.0:
* Source code package: http://grass.osgeo.org/grass70/source/ (grass-7.0.0beta1.tar.gz)
* SVN branch: http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_7_0
* SVN tag: http://trac.osgeo.org/grass/browser/grass/tags/release_20140327_grass_7_0_0beta1
* http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures
* Development started in April 2008

=== Individual reports ===
==== [[User:lucadelu|Luca Delucchi]] ====
* fix ''locn_is_latlong'' function in Python/script/core {{rev|59306}}
* fix ''v.in.geopaparazzi'' {{rev|59310}}
* update ''r.modis'' {{rev|59323}}
* update ''i.oif'' to work with several bands {{rev|59350}} {{rev|59353}} ({{trac|2057}})
* several improvement of ''g.gui.rlisetup'' {{rev|59367}} {{rev|59394}} {{rev|59424}} {{rev|59437}} {{rev|59453}}
* fix problem in r.li.setup using circle to select testing areas {{rev|59413}}

==== [[User:Neteler|Markus Neteler]] ====

* Manual intro {{cmd|helptext|version=70}}: location structure graphics beautified (contributed by Milena Nowotarska)
* demolocation: [http://www.naturalearthdata.com/downloads/110m-cultural-vectors/ country_boundaries] vector map added in {{rev|59303}}
* r.li.*: backport of rewrite in trunk to GRASS 6.4.svn in {{rev|59305}} and 6.5.svn in {{rev|59304}} ({{trac|1214}})
* walking through the [http://trac.osgeo.org/grass/report/19 GRASS 7 bug reports]
* v.what.rast: centroid support added in {{rev|59341}}
* Started to update the QGIS Processing for GRASS GIS 7 (joint work with Pirmin Kalberer)

==== [[User:Landa|Martin Landa]] ====

* Fix db.login on Windows {{rev|59318}} + {{rev|59319}}
* Update history when running module from dialog {{rev|59307}}
* Various fixes relalated to Windows - {{rev|59338}}, {{rev|59347}}
* New <tt>-gtext</tt> switch added - {{rev|59379}}

; TODO

* http://trac.osgeo.org/grass/ticket/2049

==== [[User:Turek|Stepan Turek]] ====

* WMS fixes {{rev|59312}}, {{rev|59328}} and improvements {{rev|59316}}, {{rev|59325}}, {{rev|59327}}
* WMS windows fix {{trac|1872}}
* wx plot improvements {{rev|59332}}, {{rev|59342}}
* turns support for GRASS - soon to be commited in trunk

==== [[User:Hellik|Helmut Kudrnovsky]] ====

* review of GRASS7-r.stream.*-tools (unfying keywords and options, manuals, typos, ...) - {{rev|59340}} {{rev|59363}} {{rev|59368}} {{rev|59370}} {{rev|59373}} {{rev|59377}} {{rev|59403}} {{rev|59416}} {{rev|59422}} {{rev|59423}} {{rev|59426}} {{rev|59434}} {{rev|59435}} {{rev|59438}} {{rev|59439}} {{rev|59444}} {{rev|59447}}
* review, discuss and close open tickets - {{trac|1418}} {{trac|1428}} {{trac|1940}} {{trac|2144}} {{trac|2153}}

== Photos ==

See http://vienna2014.sprint.osgeo.org/2014/03/27/photos.html

== Press release ==

TODO

Turns in the vector network analysis

2014-03-26T17:40:44Z

⚠️Turek: modules supporting turntable

{{ToModify}}

__TOC__

The turntable can be created by {{cmd|v.net|version=70}} module, which is one of [[vector network analysis]] modules.
Building the turntable allows you to model e.g. trafic code, where some turns may be prohibited.
It creates a turntable with the costs for every possible turn on every possible node (intersection, crossroad) in given layer. U-turns are taken in account too.

[[Image:Line_graph.png|center|400px|thumb| Author: Stephan Winter]]

For better handling, a linegraph is created. In this linegraph, every line is represented by two nodes. These nodes have positive and negative values respectively, with their absolute values identical. Every node corresponds to opposite line direction. The positive node matches the direction of line. The negative node matches the opposite direction. For better understanding, let's have a travelling subject standing on a line (road) before an intersection wanting to cross it. This line's direction is TOWARDS the intersection. Travelling from this line through the intersection means that the subject is currently standing on the POSITIVE node representation of the line. After crossing to this line from any permitted direction, the subject gets to the NEGATIVE point representation of the line.

These two nodes (corresponding to the same line) are connected with two U-turns (for both directions). Every U-turn direction belongs to another intersection. U-turn from the POSITIVE node to the NEGATIVE one belongs to the intersection we are going to cross. The other U-turn belongs to the intersection at the opposite end of this line.

'''If features in analyzed network are changed, the turntable must be created again (e.g. it includes v.net connect operation). '''

==Turntable description==

Every record in the turntable represents one turn.

'''Columns description:'''

* '''cat''' – category in '''tlayer''' (layer with turntable), which corresponds to both lines in turn

* '''ln_from''' – unique category in '''tuclayer''' layer assigned to the starting line of the turn

* '''ln_to''' – unique category in '''tuclayer''' layer assigned to the ending line line of the turn

* '''cost''' – cost for turn (integer or double), assign -1 to close the turn

* '''isec''' – point category in '''tulayer''' layer, which represents the intersection, where the turn belongs

* '''angle''' – angle between the lines before and after the intersection (radians), positive -> turn to the right, negative -> turn to the left, 0 -> straight

[[Image:Turntable.png|center|800px|thumb]]

Every possible turn on any possible intersection is represented by unique record (line).
In the picture above you can see the turntable and part of vector layer with highlighted turn from the line with unique category 289 through the node (intersection) 561 to the line with unique category 234. In other words the given subject travels from intersection 564 through intersection 561 to intersection 527.

Arrows show orientation of each line. Note that in case of the line 289 the subject travels in BACKWARDS direction and therefore the In_from value is NEGATIVE (-289) while in case of the line 234 the travelling is in FORWARD direction, so the In_from value is POSITIVE (234).
The category of this turn can be seen in the cat column and the value is 1817 (this kind of category is stored in tlayer). This category value belongs only to the lines with unique category values 234 and 289 (stored in tuclayer).

In the angle column for this record the value is -1.373597 radians which is roughly -80°. This perfectly makes sense since left turns have negative values and right turns have positive. The angle is measured as deviance from straight direction (which is 0°).

== Modules working with turntable ==

* {{cmd|v.net|version=70}} - creates the turntable

* {{cmd|v.net.path|version=70}}

* {{cmd|v.net.alloc|version=70}}

* {{cmd|v.net.iso|version=70}}

* {{cmd|v.net.salesman|version=70}}
=== Specific parameters of modules working with turntable ===

* '''alayer''' - Name or number of the arc layer that will be expanded by turntable.

* '''tlayer''' - Name or number of the layer to which the turntable will be attached.

* '''tuclayer''' - Name or number of the layer with unique categories for every line and point. The points are placed on every node.

==WxGUI Vector Network Analysis Tool==

In GUI for v.net modules there is the checkbox option to “use turns”. If checked, it is required to fill these additional parameters: tlayer (layer with turntable), tuclayer (layer with unique categories for turntable). The dialog is shown below.

[[Image:Params_ttb.png|center|400px|thumb]]

It is possible to predefine costs for default or custom angle intervals in the Global settings dialog as shown in picture below.

[[Image:Global_ttb.png|center|400px|thumb]]

The angle, however, is only the simple one between two straight lines (from previous intersection to current node and from current intersection to the next one ignoring any original shorter polyline segments).
After the turntable is created, it is possible to customize costs explicitly for any specific turn on any given intersection (node) via the Local settings dialog.

[[Image:Local_ttb.png|center|400px|thumb]]

==Further Reading==

[ftp://ftp.geoinfo.tuwien.ac.at/winter/winter02modeling.pdf Modeling Costs of Turns in Route Planning]

[[Category:Documentation]]
[[Category:Vector]]
[[Category:Network Analysis]]

Talk:GRASS Community Sprint Vienna 2014

2014-03-26T15:30:36Z

⚠️Turek: /* Reports */

== Reports ==

Way over 50 participants here present!

=== [[User:lucadelu|Luca Delucchi]] ===
* fix ''locn_is_latlong'' function in Python/script/core {{rev|59306}}
* fix ''v.in.geopaparazzi'' {{rev|59310}}
* update ''r.modis'' {{rev|59323}}
* update ''i.oif'' to work with several bands {{rev|59350}} {{rev|59353}} ({{trac|2057}})

=== [[User:Neteler|Markus Neteler]] ===

* Manual intro {{cmd|helptext|version=70}}: location structure graphics beautified (contributed by Milena Nowotarska)
* demolocation: [http://www.naturalearthdata.com/downloads/110m-cultural-vectors/ country_boundaries] vector map added in {{rev|59303}}
* r.li.*: backport of rewrite in trunk to GRASS 6.4.svn in {{rev|59305}} and 6.5.svn in {{rev|59304}} ({{trac|1214}})
* walking through the [http://trac.osgeo.org/grass/report/19 GRASS 7 bug reports]
* v.what.rast: centroid support added in {{rev|59341}}

=== [[User:Landa|Martin Landa]] ===

* Fix db.login on Windows {{rev|59318}} + {{rev|59319}}
* Update history when running module from dialog {{rev|59307}}
* Various fixes relalated to Windows - {{rev|59338}}, {{rev|59347}}
; TODO

* http://trac.osgeo.org/grass/ticket/2049

=== [[User:Turek|Stepan Turek]] ===

* WMS fixes {{rev|59312}}, {{rev|59328}} and improvements {{rev|59316}}, {{rev|59325}}, {{rev|59327}}
* WMS windows fix {{trac|1872}}
* wx plot improvements {{rev|59332}}, {{rev|59342}}

== Press release ==

TODO

Talk:GRASS Community Sprint Vienna 2014

2014-03-25T09:31:22Z

⚠️Turek: /* Reports */ +Turek Monday

== Reports ==

Way over 50 participants here present!

=== [[User:lucadelu|Luca Delucchi]] ===
* fix ''locn_is_latlong'' function in Python/script/core {{rev|59306}}
* fix v.in.geopaparazzi {{rev|59310}}

=== [[User:Neteler|Markus Neteler]] ===

* Manual intro {{cmd|helptext|version=70}}: location structure graphics beautified (contributed by Milena Nowotarska)
* demolocation: [http://www.naturalearthdata.com/downloads/110m-cultural-vectors/ country_boundaries] vector map added {{rev|59303}}
* r.li.*: backport of rewrite in trunk to GRASS 6.4.svn in {{rev|59305}} and 6.5.svn in {{rev|59304}} ({{trac|1214}})

=== [[User:Landa|Martin Landa]] ===

* Fix db.login on Windows {{rev|59318}} + {{rev|59319}}
* Update history when running module from dialog {{rev|59307}}

=== [[User:Turek|Stepan Turek]] ===

* WMS fixes {{rev|59312}} and improvements {{rev|59316}}
; TODO

* http://trac.osgeo.org/grass/ticket/2049

== Press release ==

TODO

Turns in the vector network analysis

2014-03-10T14:41:09Z

⚠️Turek:

{{ToModify}}

__TOC__

The turntable can be created by {{cmd|v.net|version=70}} module, which is one of [[vector network analysis]] modules.
Building the turntable allows you to model e.g. trafic code, where some turns may be prohibited.
It creates a turntable with the costs for every possible turn on every possible node (intersection, crossroad) in given layer. U-turns are taken in account too.

[[Image:Line_graph.png|center|400px|thumb| Author: Stephan Winter]]

For better handling, a linegraph is created. In this linegraph, every line is represented by two nodes. These nodes have positive and negative values respectively, with their absolute values identical. Every node corresponds to opposite line direction. The positive node matches the direction of line. The negative node matches the opposite direction. For better understanding, let's have a travelling subject standing on a line (road) before an intersection wanting to cross it. This line's direction is TOWARDS the intersection. Travelling from this line through the intersection means that the subject is currently standing on the POSITIVE node representation of the line. After crossing to this line from any permitted direction, the subject gets to the NEGATIVE point representation of the line.

These two nodes (corresponding to the same line) are connected with two U-turns (for both directions). Every U-turn direction belongs to another intersection. U-turn from the POSITIVE node to the NEGATIVE one belongs to the intersection we are going to cross. The other U-turn belongs to the intersection at the opposite end of this line.

'''If features in analyzed network are changed, the turntable must be created again (e.g. it includes v.net connect operation). '''

==Turntable description==

Every record in the turntable represents one turn.

'''Columns description:'''

* '''cat''' – category in '''tlayer''' (layer with turntable), which corresponds to both lines in turn

* '''ln_from''' – unique category in '''tuclayer''' layer assigned to the starting line of the turn

* '''ln_to''' – unique category in '''tuclayer''' layer assigned to the ending line line of the turn

* '''cost''' – cost for turn (integer or double), assign -1 to close the turn

* '''isec''' – point category in '''tulayer''' layer, which represents the intersection, where the turn belongs

* '''angle''' – angle between the lines before and after the intersection (radians), positive -> turn to the right, negative -> turn to the left, 0 -> straight

[[Image:Turntable.png|center|800px|thumb]]

Every possible turn on any possible intersection is represented by unique record (line).
In the picture above you can see the turntable and part of vector layer with highlighted turn from the line with unique category 289 through the node (intersection) 561 to the line with unique category 234. In other words the given subject travels from intersection 564 through intersection 561 to intersection 527.

Arrows show orientation of each line. Note that in case of the line 289 the subject travels in BACKWARDS direction and therefore the In_from value is NEGATIVE (-289) while in case of the line 234 the travelling is in FORWARD direction, so the In_from value is POSITIVE (234).
The category of this turn can be seen in the cat column and the value is 1817 (this kind of category is stored in tlayer). This category value belongs only to the lines with unique category values 234 and 289 (stored in tuclayer).

In the angle column for this record the value is -1.373597 radians which is roughly -80°. This perfectly makes sense since left turns have negative values and right turns have positive. The angle is measured as deviance from straight direction (which is 0°).

== Specific parameters ==

* '''alayer''' - Name or number of the arc layer that will be expanded by turntable.

* '''tlayer''' - Name or number of the layer to which the turntable will be attached.

* '''tuclayer''' - Name or number of the layer with unique categories for every line and point. The points are placed on every node.

==WxGUI Vector Network Analysis Tool==

In GUI for v.net modules there is the checkbox option to “use turns”. If checked, it is required to fill these additional parameters: tlayer (layer with turntable), tuclayer (layer with unique categories for turntable). The dialog is shown below.

[[Image:Params_ttb.png|center|400px|thumb]]

It is possible to predefine costs for default or custom angle intervals in the Global settings dialog as shown in picture below.

[[Image:Global_ttb.png|center|400px|thumb]]

The angle, however, is only the simple one between two straight lines (from previous intersection to current node and from current intersection to the next one ignoring any original shorter polyline segments).
After the turntable is created, it is possible to customize costs explicitly for any specific turn on any given intersection (node) via the Local settings dialog.

[[Image:Local_ttb.png|center|400px|thumb]]

==Further Reading==

[ftp://ftp.geoinfo.tuwien.ac.at/winter/winter02modeling.pdf Modeling Costs of Turns in Route Planning]

[[Category:Documentation]]
[[Category:Vector]]
[[Category:Network Analysis]]

Turns in the vector network analysis

2014-03-10T14:36:45Z

⚠️Turek: /* Turntable description */

{{ToModify}}

__TOC__

The turntable can be created by {{cmd|v.net|version=70}} module, which is one of [[vector network analysis]] modules.
Building the turntable allows you to model e.g. trafic code, where some turns may be prohibited.
It creates a turntable with the costs for every possible turn on every possible node (intersection, crossroad) in given layer. U-turns are taken in account too.

[[Image:Line_graph.png|center|400px|thumb| Author: Stephan Winter]]

For better handling, a linegraph is created. In this linegraph, every line is represented by two nodes. These nodes have positive and negative values respectively, with their absolute values identical. Every node corresponds to opposite line direction. The positive node matches the direction of line. The negative node matches the opposite direction. For better understanding, let's have a travelling subject standing on a line (road) before an intersection wanting to cross it. This line's direction is TOWARDS the intersection. Travelling from this line through the intersection means that the subject is currently standing on the POSITIVE node representation of the line. After crossing to this line from any permitted direction, the subject gets to the NEGATIVE point representation of the line.

These two nodes (corresponding to the same line) are connected with two U-turns (for both directions). Every U-turn direction belongs to another intersection. U-turn from the POSITIVE node to the NEGATIVE one belongs to the intersection we are going to cross. The other U-turn belongs to the intersection at the opposite end of this line.

==Turntable description==

Every record in the turntable represents one turn.

'''Columns description:'''

* '''cat''' – category in '''tlayer''' (layer with turntable), which corresponds to both lines in turn

* '''ln_from''' – unique category in '''tuclayer''' layer assigned to the starting line of the turn

* '''ln_to''' – unique category in '''tuclayer''' layer assigned to the ending line line of the turn

* '''cost''' – cost for turn (integer or double), assign -1 to close the turn

* '''isec''' – point category in '''tulayer''' layer, which represents the intersection, where the turn belongs

* '''angle''' – angle between the lines before and after the intersection (radians), positive -> turn to the right, negative -> turn to the left, 0 -> straight

[[Image:Turntable.png|center|800px|thumb]]

Every possible turn on any possible intersection is represented by unique record (line).
In the picture above you can see the turntable and part of vector layer with highlighted turn from the line with unique category 289 through the node (intersection) 561 to the line with unique category 234. In other words the given subject travels from intersection 564 through intersection 561 to intersection 527.

Arrows show orientation of each line. Note that in case of the line 289 the subject travels in BACKWARDS direction and therefore the In_from value is NEGATIVE (-289) while in case of the line 234 the travelling is in FORWARD direction, so the In_from value is POSITIVE (234).
The category of this turn can be seen in the cat column and the value is 1817 (this kind of category is stored in tlayer). This category value belongs only to the lines with unique category values 234 and 289 (stored in tuclayer).

In the angle column for this record the value is -1.373597 radians which is roughly -80°. This perfectly makes sense since left turns have negative values and right turns have positive. The angle is measured as deviance from straight direction (which is 0°).

== Specific parameters ==

* '''alayer''' - Name or number of the arc layer that will be expanded by turntable.

* '''tlayer''' - Name or number of the layer to which the turntable will be attached.

* '''tuclayer''' - Name or number of the layer with unique categories for every line and point. The points are placed on every node.

==WxGUI Vector Network Analysis Tool==

In GUI for v.net modules there is the checkbox option to “use turns”. If checked, it is required to fill these additional parameters: tlayer (layer with turntable), tuclayer (layer with unique categories for turntable). The dialog is shown below.

[[Image:Params_ttb.png|center|400px|thumb]]

It is possible to predefine costs for default or custom angle intervals in the Global settings dialog as shown in picture below.

[[Image:Global_ttb.png|center|400px|thumb]]

The angle, however, is only the simple one between two straight lines (from previous intersection to current node and from current intersection to the next one ignoring any original shorter polyline segments).
After the turntable is created, it is possible to customize costs explicitly for any specific turn on any given intersection (node) via the Local settings dialog.

[[Image:Local_ttb.png|center|400px|thumb]]

==Further Reading==

[ftp://ftp.geoinfo.tuwien.ac.at/winter/winter02modeling.pdf Modeling Costs of Turns in Route Planning]

[[Category:Documentation]]
[[Category:Vector]]
[[Category:Network Analysis]]

Turns in the vector network analysis

2014-03-10T14:29:33Z

⚠️Turek: /* Turntable description (the table itself) */

{{ToModify}}

__TOC__

The turntable can be created by {{cmd|v.net|version=70}} module, which is one of [[vector network analysis]] modules.
Building the turntable allows you to model e.g. trafic code, where some turns may be prohibited.
It creates a turntable with the costs for every possible turn on every possible node (intersection, crossroad) in given layer. U-turns are taken in account too.

[[Image:Line_graph.png|center|400px|thumb| Author: Stephan Winter]]

For better handling, a linegraph is created. In this linegraph, every line is represented by two nodes. These nodes have positive and negative values respectively, with their absolute values identical. Every node corresponds to opposite line direction. The positive node matches the direction of line. The negative node matches the opposite direction. For better understanding, let's have a travelling subject standing on a line (road) before an intersection wanting to cross it. This line's direction is TOWARDS the intersection. Travelling from this line through the intersection means that the subject is currently standing on the POSITIVE node representation of the line. After crossing to this line from any permitted direction, the subject gets to the NEGATIVE point representation of the line.

These two nodes (corresponding to the same line) are connected with two U-turns (for both directions). Every U-turn direction belongs to another intersection. U-turn from the POSITIVE node to the NEGATIVE one belongs to the intersection we are going to cross. The other U-turn belongs to the intersection at the opposite end of this line.

==Turntable description==

Every record in the turntable represents one turn.

'''Columns description:'''

* '''cat''' – category in tlayer (layer with turntable), which corresponds to both lines in turn

* '''ln_from''' – unique category in tucats layer assigned to the starting line of the turn

* '''ln_to''' – unique category in tucats layer assigned to the ending line line of the turn

* '''cost''' – cost for turn (integer or double)

* '''isec''' – point category in tucats layer, which represents the intersection, where the turn belongs

* '''angle''' – angle between the lines before and after the intersection (radians), positive -> turn to the right, negative -> turn to the left, 0 -> straight

[[Image:Turntable.png|center|800px|thumb]]

Every possible turn on any possible intersection is represented by unique record (line).
In the picture above you can see the turntable and part of vector layer with highlighted turn from the line with unique category 289 through the node (intersection) 561 to the line with unique category 234. In other words the given subject travels from intersection 564 through intersection 561 to intersection 527.

Arrows show orientation of each line. Note that in case of the line 289 the subject travels in BACKWARDS direction and therefore the In_from value is NEGATIVE (-289) while in case of the line 234 the travelling is in FORWARD direction, so the In_from value is POSITIVE (234).
The category of this turn can be seen in the cat column and the value is 1817 (this kind of category is stored in tlayer). This category value belongs only to the lines with unique category values 234 and 289 (stored in tuclayer).

In the angle column for this record the value is -1.373597 radians which is roughly -80°. This perfectly makes sense since left turns have negative values and right turns have positive. The angle is measured as deviance from straight direction (which is 0°).

== Specific parameters ==

* '''alayer''' - Name or number of the arc layer that will be expanded by turntable.

* '''tlayer''' - Name or number of the layer to which the turntable will be attached.

* '''tuclayer''' - Name or number of the layer with unique categories for every line and point. The points are placed on every node.

==WxGUI Vector Network Analysis Tool==

In GUI for v.net modules there is the checkbox option to “use turns”. If checked, it is required to fill these additional parameters: tlayer (layer with turntable), tuclayer (layer with unique categories for turntable). The dialog is shown below.

[[Image:Params_ttb.png|center|400px|thumb]]

It is possible to predefine costs for default or custom angle intervals in the Global settings dialog as shown in picture below.

[[Image:Global_ttb.png|center|400px|thumb]]

The angle, however, is only the simple one between two straight lines (from previous intersection to current node and from current intersection to the next one ignoring any original shorter polyline segments).
After the turntable is created, it is possible to customize costs explicitly for any specific turn on any given intersection (node) via the Local settings dialog.

[[Image:Local_ttb.png|center|400px|thumb]]

==Further Reading==

[ftp://ftp.geoinfo.tuwien.ac.at/winter/winter02modeling.pdf Modeling Costs of Turns in Route Planning]

[[Category:Documentation]]
[[Category:Vector]]
[[Category:Network Analysis]]

Turns in the vector network analysis

2014-03-10T14:28:10Z

⚠️Turek:

{{ToModify}}

__TOC__

The turntable can be created by {{cmd|v.net|version=70}} module, which is one of [[vector network analysis]] modules.
Building the turntable allows you to model e.g. trafic code, where some turns may be prohibited.
It creates a turntable with the costs for every possible turn on every possible node (intersection, crossroad) in given layer. U-turns are taken in account too.

[[Image:Line_graph.png|center|400px|thumb| Author: Stephan Winter]]

For better handling, a linegraph is created. In this linegraph, every line is represented by two nodes. These nodes have positive and negative values respectively, with their absolute values identical. Every node corresponds to opposite line direction. The positive node matches the direction of line. The negative node matches the opposite direction. For better understanding, let's have a travelling subject standing on a line (road) before an intersection wanting to cross it. This line's direction is TOWARDS the intersection. Travelling from this line through the intersection means that the subject is currently standing on the POSITIVE node representation of the line. After crossing to this line from any permitted direction, the subject gets to the NEGATIVE point representation of the line.

These two nodes (corresponding to the same line) are connected with two U-turns (for both directions). Every U-turn direction belongs to another intersection. U-turn from the POSITIVE node to the NEGATIVE one belongs to the intersection we are going to cross. The other U-turn belongs to the intersection at the opposite end of this line.

==Turntable description (the table itself)==

Every record in the turntable represents one turn.

'''Columns description:'''

* '''cat''' – category in tlayer (layer with turntable), which corresponds to both lines in turn

* '''ln_from''' – unique category in tucats layer assigned to the starting line of the turn

* '''ln_to''' – unique category in tucats layer assigned to the ending line line of the turn

* '''cost''' – cost for turn (integer or double)

* '''isec''' – point category in tucats layer, which represents the intersection, where the turn belongs

* '''angle''' – angle between the lines before and after the intersection (radians), positive -> turn to the right, negative -> turn to the left, 0 -> straight

[[Image:Turntable.png|center|800px|thumb]]

Every possible turn on any possible intersection is represented by unique record (line).
In the picture above you can see the turntable and part of vector layer with highlighted turn from the line with unique category 289 through the node (intersection) 561 to the line with unique category 234. In other words the given subject travels from intersection 564 through intersection 561 to intersection 527.

Arrows show orientation of each line. Note that in case of the line 289 the subject travels in BACKWARDS direction and therefore the In_from value is NEGATIVE (-289) while in case of the line 234 the travelling is in FORWARD direction, so the In_from value is POSITIVE (234).
The category of this turn can be seen in the cat column and the value is 1817 (this kind of category is stored in tlayer). This category value belongs only to the lines with unique category values 234 and 289 (stored in tuclayer).

In the angle column for this record the value is -1.373597 radians which is roughly -80°. This perfectly makes sense since left turns have negative values and right turns have positive. The angle is measured as deviance from straight direction (which is 0°).

== Specific parameters ==

* '''alayer''' - Name or number of the arc layer that will be expanded by turntable.

* '''tlayer''' - Name or number of the layer to which the turntable will be attached.

* '''tuclayer''' - Name or number of the layer with unique categories for every line and point. The points are placed on every node.

==WxGUI Vector Network Analysis Tool==

In GUI for v.net modules there is the checkbox option to “use turns”. If checked, it is required to fill these additional parameters: tlayer (layer with turntable), tuclayer (layer with unique categories for turntable). The dialog is shown below.

[[Image:Params_ttb.png|center|400px|thumb]]

It is possible to predefine costs for default or custom angle intervals in the Global settings dialog as shown in picture below.

[[Image:Global_ttb.png|center|400px|thumb]]

The angle, however, is only the simple one between two straight lines (from previous intersection to current node and from current intersection to the next one ignoring any original shorter polyline segments).
After the turntable is created, it is possible to customize costs explicitly for any specific turn on any given intersection (node) via the Local settings dialog.

[[Image:Local_ttb.png|center|400px|thumb]]

==Further Reading==

[ftp://ftp.geoinfo.tuwien.ac.at/winter/winter02modeling.pdf Modeling Costs of Turns in Route Planning]

[[Category:Documentation]]
[[Category:Vector]]
[[Category:Network Analysis]]

Turns in the vector network analysis

2014-03-10T14:25:37Z

⚠️Turek:

{{ToModify}}

__TOC__

The turntable can be created by {{cmd|v.net|version=70}} module, which is one of [[vector network analysis]] modules.
It creates a turntable with the costs for every possible turn on every possible node (intersection, crossroad) in given layer. U-turns are taken in account too.

[[Image:Line_graph.png|center|400px|thumb| Author: Stephan Winter]]

For better handling, a linegraph is created. In this linegraph, every line is represented by two nodes. These nodes have positive and negative values respectively, with their absolute values identical. Every node corresponds to opposite line direction. The positive node matches the direction of line. The negative node matches the opposite direction. For better understanding, let's have a travelling subject standing on a line (road) before an intersection wanting to cross it. This line's direction is TOWARDS the intersection. Travelling from this line through the intersection means that the subject is currently standing on the POSITIVE node representation of the line. After crossing to this line from any permitted direction, the subject gets to the NEGATIVE point representation of the line.

These two nodes (corresponding to the same line) are connected with two U-turns (for both directions). Every U-turn direction belongs to another intersection. U-turn from the POSITIVE node to the NEGATIVE one belongs to the intersection we are going to cross. The other U-turn belongs to the intersection at the opposite end of this line.

==Turntable description (the table itself)==

Every record in the turntable represents one turn.

'''Columns description:'''

* '''cat''' – category in tlayer (layer with turntable), which corresponds to both lines in turn

* '''ln_from''' – unique category in tucats layer assigned to the starting line of the turn

* '''ln_to''' – unique category in tucats layer assigned to the ending line line of the turn

* '''cost''' – cost for turn (integer or double)

* '''isec''' – point category in tucats layer, which represents the intersection, where the turn belongs

* '''angle''' – angle between the lines before and after the intersection (radians), positive -> turn to the right, negative -> turn to the left, 0 -> straight

[[Image:Turntable.png|center|800px|thumb]]

Every possible turn on any possible intersection is represented by unique record (line).
In the picture above you can see the turntable and part of vector layer with highlighted turn from the line with unique category 289 through the node (intersection) 561 to the line with unique category 234. In other words the given subject travels from intersection 564 through intersection 561 to intersection 527.

Arrows show orientation of each line. Note that in case of the line 289 the subject travels in BACKWARDS direction and therefore the In_from value is NEGATIVE (-289) while in case of the line 234 the travelling is in FORWARD direction, so the In_from value is POSITIVE (234).
The category of this turn can be seen in the cat column and the value is 1817 (this kind of category is stored in tlayer). This category value belongs only to the lines with unique category values 234 and 289 (stored in tuclayer).

In the angle column for this record the value is -1.373597 radians which is roughly -80°. This perfectly makes sense since left turns have negative values and right turns have positive. The angle is measured as deviance from straight direction (which is 0°).

== Specific parameters ==

* '''alayer''' - Name or number of the arc layer that will be expanded by turntable.

* '''tlayer''' - Name or number of the layer to which the turntable will be attached.

* '''tuclayer''' - Name or number of the layer with unique categories for every line and point. The points are placed on every node.

==WxGUI Vector Network Analysis Tool==

In GUI for v.net modules there is the checkbox option to “use turns”. If checked, it is required to fill these additional parameters: tlayer (layer with turntable), tuclayer (layer with unique categories for turntable). The dialog is shown below.

[[Image:Params_ttb.png|center|400px|thumb]]

It is possible to predefine costs for default or custom angle intervals in the Global settings dialog as shown in picture below.

[[Image:Global_ttb.png|center|400px|thumb]]

The angle, however, is only the simple one between two straight lines (from previous intersection to current node and from current intersection to the next one ignoring any original shorter polyline segments).
After the turntable is created, it is possible to customize costs explicitly for any specific turn on any given intersection (node) via the Local settings dialog.

[[Image:Local_ttb.png|center|400px|thumb]]

==Further Reading==

[ftp://ftp.geoinfo.tuwien.ac.at/winter/winter02modeling.pdf Modeling Costs of Turns in Route Planning]

[[Category:Documentation]]
[[Category:Vector]]
[[Category:Network Analysis]]

File:Line graph.png

2014-03-10T14:24:26Z

⚠️Turek:

Author: Stephan Winter (winter at geoinfo.tuwien.ac.at)

Turns in the vector network analysis

2014-03-10T13:37:15Z

⚠️Turek: TOC

{{ToModify}}

__TOC__

The turntable can be created by {{cmd|v.net|version=70}} module, which is one of [[vector network analysis]] modules.
It creates a turntable with the costs for every possible turn on every possible node (intersection, crossroad) in given layer. U-turns are taken in account too.

[[Image:Line_graph.png|center|400px|thumb]]

For better handling, a linegraph is created. In this linegraph, every line is represented by two nodes. These nodes have positive and negative values respectively, with their absolute values identical. Every node corresponds to opposite line direction. The positive node matches the direction of line. The negative node matches the opposite direction. For better understanding, let's have a travelling subject standing on a line (road) before an intersection wanting to cross it. This line's direction is TOWARDS the intersection. Travelling from this line through the intersection means that the subject is currently standing on the POSITIVE node representation of the line. After crossing to this line from any permitted direction, the subject gets to the NEGATIVE point representation of the line.

These two nodes (corresponding to the same line) are connected with two U-turns (for both directions). Every U-turn direction belongs to another intersection. U-turn from the POSITIVE node to the NEGATIVE one belongs to the intersection we are going to cross. The other U-turn belongs to the intersection at the opposite end of this line.

==Turntable description (the table itself)==

Every record in the turntable represents one turn.

'''Columns description:'''

* '''cat''' – category in tlayer (layer with turntable), which corresponds to both lines in turn

* '''ln_from''' – unique category in tucats layer assigned to the starting line of the turn

* '''ln_to''' – unique category in tucats layer assigned to the ending line line of the turn

* '''cost''' – cost for turn (integer or double)

* '''isec''' – point category in tucats layer, which represents the intersection, where the turn belongs

* '''angle''' – angle between the lines before and after the intersection (radians), positive -> turn to the right, negative -> turn to the left, 0 -> straight

[[Image:Turntable.png|center|800px|thumb]]

Every possible turn on any possible intersection is represented by unique record (line).
In the picture above you can see the turntable and part of vector layer with highlighted turn from the line with unique category 289 through the node (intersection) 561 to the line with unique category 234. In other words the given subject travels from intersection 564 through intersection 561 to intersection 527.

Arrows show orientation of each line. Note that in case of the line 289 the subject travels in BACKWARDS direction and therefore the In_from value is NEGATIVE (-289) while in case of the line 234 the travelling is in FORWARD direction, so the In_from value is POSITIVE (234).
The category of this turn can be seen in the cat column and the value is 1817 (this kind of category is stored in tlayer). This category value belongs only to the lines with unique category values 234 and 289 (stored in tuclayer).

In the angle column for this record the value is -1.373597 radians which is roughly -80°. This perfectly makes sense since left turns have negative values and right turns have positive. The angle is measured as deviance from straight direction (which is 0°).

== Specific parameters ==

* '''alayer''' - Name or number of the arc layer that will be expanded by turntable.

* '''tlayer''' - Name or number of the layer to which the turntable will be attached.

* '''tuclayer''' - Name or number of the layer with unique categories for every line and point. The points are placed on every node.

==WxGUI Vector Network Analysis Tool==

In GUI for v.net modules there is the checkbox option to “use turns”. If checked, it is required to fill these additional parameters: tlayer (layer with turntable), tuclayer (layer with unique categories for turntable). The dialog is shown below.

[[Image:Params_ttb.png|center|400px|thumb]]

It is possible to predefine costs for default or custom angle intervals in the Global settings dialog as shown in picture below.

[[Image:Global_ttb.png|center|400px|thumb]]

The angle, however, is only the simple one between two straight lines (from previous intersection to current node and from current intersection to the next one ignoring any original shorter polyline segments).
After the turntable is created, it is possible to customize costs explicitly for any specific turn on any given intersection (node) via the Local settings dialog.

[[Image:Local_ttb.png|center|400px|thumb]]

==Further Reading==

[ftp://ftp.geoinfo.tuwien.ac.at/winter/winter02modeling.pdf Modeling Costs of Turns in Route Planning]

[[Category:Documentation]]
[[Category:Vector]]
[[Category:Network Analysis]]

Turns in the vector network analysis

2014-03-10T13:30:26Z

⚠️Turek:

{{ToModify}}

The turntable can be created by {{cmd|v.net|version=70}} module, which is one of [[vector network analysis]] modules.
It creates a turntable with the costs for every possible turn on every possible node (intersection, crossroad) in given layer. U-turns are taken in account too.

[[Image:Line_graph.png|center|400px|thumb]]

For better handling, a linegraph is created. In this linegraph, every line is represented by two nodes. These nodes have positive and negative values respectively, with their absolute values identical. Every node corresponds to opposite line direction. The positive node matches the direction of line. The negative node matches the opposite direction. For better understanding, let's have a travelling subject standing on a line (road) before an intersection wanting to cross it. This line's direction is TOWARDS the intersection. Travelling from this line through the intersection means that the subject is currently standing on the POSITIVE node representation of the line. After crossing to this line from any permitted direction, the subject gets to the NEGATIVE point representation of the line.

These two nodes (corresponding to the same line) are connected with two U-turns (for both directions). Every U-turn direction belongs to another intersection. U-turn from the POSITIVE node to the NEGATIVE one belongs to the intersection we are going to cross. The other U-turn belongs to the intersection at the opposite end of this line.

==Turntable description (the table itself)==

Every record in the turntable represents one turn.

'''Columns description:'''

* '''cat''' – category in tlayer (layer with turntable), which corresponds to both lines in turn

* '''ln_from''' – unique category in tucats layer assigned to the starting line of the turn

* '''ln_to''' – unique category in tucats layer assigned to the ending line line of the turn

* '''cost''' – cost for turn (integer or double)

* '''isec''' – point category in tucats layer, which represents the intersection, where the turn belongs

* '''angle''' – angle between the lines before and after the intersection (radians), positive -> turn to the right, negative -> turn to the left, 0 -> straight

[[Image:Turntable.png|center|800px|thumb]]

Every possible turn on any possible intersection is represented by unique record (line).
In the picture above you can see the turntable and part of vector layer with highlighted turn from the line with unique category 289 through the node (intersection) 561 to the line with unique category 234. In other words the given subject travels from intersection 564 through intersection 561 to intersection 527.

Arrows show orientation of each line. Note that in case of the line 289 the subject travels in BACKWARDS direction and therefore the In_from value is NEGATIVE (-289) while in case of the line 234 the travelling is in FORWARD direction, so the In_from value is POSITIVE (234).
The category of this turn can be seen in the cat column and the value is 1817 (this kind of category is stored in tlayer). This category value belongs only to the lines with unique category values 234 and 289 (stored in tuclayer).

In the angle column for this record the value is -1.373597 radians which is roughly -80°. This perfectly makes sense since left turns have negative values and right turns have positive. The angle is measured as deviance from straight direction (which is 0°).

== Specific parameters ==

* '''alayer''' - Name or number of the arc layer that will be expanded by turntable.

* '''tlayer''' - Name or number of the layer to which the turntable will be attached.

* '''tuclayer''' - Name or number of the layer with unique categories for every line and point. The points are placed on every node.

==WxGUI Vector Network Analysis Tool==

In GUI for v.net modules there is the checkbox option to “use turns”. If checked, it is required to fill these additional parameters: tlayer (layer with turntable), tuclayer (layer with unique categories for turntable). The dialog is shown below.

[[Image:Params_ttb.png|center|400px|thumb]]

It is possible to predefine costs for default or custom angle intervals in the Global settings dialog as shown in picture below.

[[Image:Global_ttb.png|center|400px|thumb]]

The angle, however, is only the simple one between two straight lines (from previous intersection to current node and from current intersection to the next one ignoring any original shorter polyline segments).
After the turntable is created, it is possible to customize costs explicitly for any specific turn on any given intersection (node) via the Local settings dialog.

[[Image:Local_ttb.png|center|400px|thumb]]

==Further Reading==

[ftp://ftp.geoinfo.tuwien.ac.at/winter/winter02modeling.pdf Modeling Costs of Turns in Route Planning]

[[Category:Documentation]]
[[Category:Vector]]
[[Category:Network Analysis]]

GRASS GSoC 2013 GRASS GIS Interactive Scatter Plot Tool

2014-02-05T22:38:52Z

⚠️Turek: /* Project plan */

{{GSoC}}
{{wxGUI}}
''(See also other [[GRASS_SoC_Ideas_2013#Accepted_Ideas|GRASS GSoC 2013 projects]])''
{| {{table}}
|Student Name: || Stepan Turek, [http://www.cvut.cz Czech Technical University in Prague]
|-
|Organization: || [http://www.osgeo.org OSGeo - Open Source Geospatial Foundation]
|-
| Mentor Name: || [http://grass.osgeo.org/wiki/User:Landa Martin Landa] Backup mentor: Michael Barton
|-
| Title: || '''GRASS GIS Interactive Scatter Plot Tool'''
|-
| Repository: || sandbox, browse at: [https://trac.osgeo.org/grass/browser/sandbox/turek/scatter_plot scatter_plot]
|-
|}

;Abstract

Goal of the project is development of interactive scatter plot tool, which will be integrated into [[wxGUI]]. The tool will improve GRASS GIS supervised classification workflow. Also it will be useful for raster data analysis in general. Additional goal is extension of GRASS GIS plotting capability by integration of [http://matplotlib.org/ Matplotlib plotting library] into wxGUI.

__TOC__
== Application ==

=== Introduction ===

Common analysis, performed on remote sensing data, is supervised classification. GRASS GIS offers necessary tools needed for performing classification workflow. However, there are some weak spots, which can be improved.

One of such a spot is limited real time analyzing of classes (categories) according to chosen data in training areas. Recently, the process of training area selection has been significantly improved by [[wxGUI Supervised Classification Tool]]. This tool simplifies definition of classes and their training areas. It also allows to show some basic statistics for classes and bands.

GRASS GIS has Bivariate Scatterplot Tool, which creates scatter plot for selected bands combination. However this tool is not connected with the Supervised Classification Tool and therefore it can not be used in process of training areas selection.

=== The idea ===

Main idea of the project is development of tool, which would allow to look at raster data from new points of view unveiling relations, which otherwise would stay hidden.

The tool would be fully integrated into wxGUI therefore it will be connected with already existing components (Map display window and the Supervised Classification Tool).

Thanks to the connection with the Supervised Classification Tool it will be possible to highlight plotted points according to currently chosen pixels for classes by it's training areas. Thanks to this information user will be able to gradually change configuration of training areas achieving better classes separability during supervised classification. Also the tool will be able to plot confidence ellipses for classes.

The scatter plot tool will be able to work with multiple plots, which will represent multiple raster bands combinations. It will be useful for imagery data, which are usually comprised from more than two bands. All such a plots will be interactively connected, therefore user will be able to define areas in plots and the tool will highlight pixels in map display window and corresponding points in other plots. These areas will be grouped into categories and there will be kind of category manager, which will allow to define the categories plotting order, plotting style etc.

Also it can be used for pure pixels identification. If bands of principal component analysis of analysed imagery data will be added into the tool, it will be possible to identify endmember points, which lie in a corners of PCA space scatter plot. It will be possible to see the pure pixels in map display window and corresponding points in other plots by selection of these points. The pure pixels are suitable to be used as class training areas, because they are not mixed with other classes (endmembers) and therefore they represent only surface of individual class (endmember).

It will be possible to create training areas from scatter plot. This feature could be used for creation of training areas from pure pixels.

The tool could be useful for analyzing of raster data in general, therefore it will be also integrated into Map display window. For instance, it could help to see correlation of analyzed data or detect outliers. It will be possible to create mask from selected pixels belonging to some category. Using this feature it will be possible to easily get rid of the effect of the outliers in subsequent analyses.

Because analyzed data can have big size, significant attention will be paid to make the tool memory efficient and fast.

Plotting part of the tool will use Matplotlib library.
The library will be integrated into wxGUI. The integration should make plotting in wxGUI easier and plotting code reusable e. g. settings of plot properties or implementation of more abstract functions.

Exact way of integration will be determined when I will be more experience with usage of Matplotlib.

Usage of integrated Matplotlib will be demonstrated by development of feature, which allows to create different graph types (e. g. line graph, bar graph) from data in vector maps or raster maps.

=== Project plan ===
{| {{table}}
|-
!Period !! Task !! Status !! Notes
|-
|May 27 - June 16 || Bonding period || {{done}} ||
|-
|June 17 || back-end integration with map window || {{done}} ||
|-
|June 24 || back-end integration with map window || {{done}} ||
|-
|July 1 || back-end integration with [[wxGUI Supervised Classification Tool]] || {{done}} ||
|-
|July 8 || back-end integration with wxGUI Supervised Classification Tool || {{done}} ||
|-
|July 15 || back-end integration with wxGUI Supervised Classification Tool||{{done}} ||
|-
|July 22 || testing and optimization of back-end || {{done}} ||
|-
|July 29 || testing and optimization of back-end || {{done}} ||
|-
|'''August 2''' || Mid-term evaluation The goal: back-end is finished || {{done}} || passed
|-
|August 5 || design of Matplotlib integration into wxGUI || ||
|-
|August 12 || development of front end of the scatter plot tool || {{done}} ||
|-
|August 19 || development of front end of the scatter plot tool || {{done}} ||
|-
|August 26 || development of front end of the scatter plot tool || {{done}} ||
|-
|September 2 ||implementation of the plotting feature for vector/raster data || ||
|-
|September 9 ||implementation of the plotting feature for vector/raster data || ||
|-
|September 16 ||testing, documentation || {{done}} ||
|-
|'''September 23'''|| Final evaluation || || passed
|}

== Testing ==

Currently testing is possible applying [https://trac.osgeo.org/grass/browser/sandbox/turek/scatter_plot/testing_patch.diff testing_patch.diff] to GRASS 7 from [https://trac.osgeo.org/grass/browser/sandbox/turek/scatter_plot sandbox] repository.

cd grass_trunk
wget http://svn.osgeo.org/grass/sandbox/turek/scatter_plot/testing_patch.diff
patch -p0 < testing_patch.diff
make

Open [[wxGUI Supervised Classification Tool]] and from toolbar click on Open Scatter Plot Tool.

== Roadmap ==

=== Week 1 (June 17) ===

* worked on integration of the scatter plot tool with mapwindow

=== Week 2 (June 24) ===

* implemented highlighting of pixels in mapwidnow according to selected areas in scatter plots

<center>
{|
|-
| [[Image:Scatter_plots_mapwin_connection.png|700px|thumb|Highlighted pixels in mapwindow (red color) corresponding to selected areas in scatter plots (green color) (2013-7-21)]]
|-
|}
</center>

=== Week 3 (July 8) ===

* studying raster library

=== Week 4 (July 15) ===

* multiprocessing module, integration of raster library into the backend

=== Week 5 (July 22) ===

* integration into wxIClass

<center>
{|

{{youTube|x3ZerMfiSOk|desc=Backend preview}}
|}
</center>

=== Week 6 (July 29) ===

* worked on releasing of alpha version -
** bugs fixing
** backend optimization
** better integration with wxIClass
* released all source code [https://trac.osgeo.org/grass/browser/sandbox/turek/ sandbox] (alpha version)

=== Week 7 (August 5) ===

* backend optimization + testing
* clarified project plan for rest of GSoC with mentor

=== Week 8 (August 12) ===

* worked on layout of frontend in [[wxIClass]]

<center>
{|
|-
| [[Image:Scatter_plot_new_layout.png|700px|thumb|New layout of the scatter plot tool in wx.IClass (2013-8-10)]]
|-
|}
</center>

=== Week 9 (August 19) ===
* worked polygon selection

=== Week 10 (August 26) ===

* implemented selection of areas by polygons in scatter plots and plotting of confidence ellipses

<center>
{|
|-
| [[Image:Selection_by_polygon_and_ellipses.png|700px|thumb|Selection of categories by polygons and plotting confidence ellipses (2013-8-26)]]
|-
|}
</center>

=== Week 11 (September 2) ===

* plots rendering optimization including speeding up and reducing memory consumption
** much better plotting separation from WxGUI thread. now only small part of plotting runs in wxGUI thread (because is directly connected to wxGUI)
** creating composite image of categories by numpy (including transparency support), thanks to that only one merged image is added into scatter plot representing all categories
** discussed and implemented advises from matplotlib comunity about memory reduction of plotting scatter plots for 12 bit data [http://matplotlib.1069221.n5.nabble.com/plotting-large-images-td41905.html see]
* thanks to that it is possible to analyze 12 bit raster data

=== Week 12 (September 9) ===

* bugs fixing, optimalization

=== Week 13 (September 16) ===

* integration into main gui, bugs fixing

<center>
{|
|-
| [[Image:Mapdisplay iscatt.png|700px|thumb|Scatter plot tool integrated into main gui (2013-9-13)]]
|-
|}
</center>

=== Week 14 (September 23) ===

* documentation, video tutorial, various fixes and improvements
* tool [[WxGUI Interactive Scatter Plot Tool|wiki page]]
{{YouTube|umNLISWzTlk}}

== Weekly Reports ==
* [http://lists.osgeo.org/pipermail/soc/2013-June/002144.html #1 (2013/06/21)]
* [http://lists.osgeo.org/pipermail/soc/2013-June/002171.html #2 (2013/06/29)]
* [http://lists.osgeo.org/pipermail/soc/2013-July/002200.html #3 (2013/07/06)]
* [http://lists.osgeo.org/pipermail/soc/2013-July/002225.html #4 (2013/07/12)]
* [http://lists.osgeo.org/pipermail/soc/2013-July/002268.html #5 (2013/07/21)]
* [http://lists.osgeo.org/pipermail/soc/2013-July/002284.html #6 (2013/07/26)]
* [http://lists.osgeo.org/pipermail/soc/2013-August/002315.html #7 (2013/08/02)]
* [http://lists.osgeo.org/pipermail/soc/2013-August/002336.html #8 (2013/08/10)]
* [http://lists.osgeo.org/pipermail/soc/2013-August/002355.html #9 (2013/08/17)]
* [http://lists.osgeo.org/pipermail/soc/2013-August/002376.html #10 (2013/08/24)]
* [http://lists.osgeo.org/pipermail/soc/2013-August/002388.html #11 (2013/08/30)]
* [http://lists.osgeo.org/pipermail/soc/2013-September/002407.html #12 (2013/09/06)]

Turns in the vector network analysis

2013-10-04T21:20:07Z

⚠️Turek: /* Headline text */

== Headline text ==
{{ToModify}}

The turntable can be created by {{cmd|v.net|version=70}} module, which is one of [[vector network analysis]] modules.
It creates a turntable with the costs for every possible turn on every possible node (intersection, crossroad) in given layer. U-turns are taken in account too.

[[Image:Line_graph.png|center|400px|thumb]]

For better handling, a linegraph is created. In this linegraph, every line is represented by two nodes. These nodes have positive and negative values respectively, with their absolute values identical. Every node corresponds to opposite line direction. The positive node matches the direction of line. The negative node matches the opposite direction. For better understanding, let's have a travelling subject standing on a line (road) before an intersection wanting to cross it. This line's direction is TOWARDS the intersection. Travelling from this line through the intersection means that the subject is currently standing on the POSITIVE node representation of the line. After crossing to this line from any permitted direction, the subject gets to the NEGATIVE point representation of the line.

These two nodes (corresponding to the same line) are connected with two U-turns (for both directions). Every U-turn direction belongs to another intersection. U-turn from the POSITIVE node to the NEGATIVE one belongs to the intersection we are going to cross. The other U-turn belongs to the intersection at the opposite end of this line.

==Turntable description (the table itself)==

Every record in the turntable represents one turn.

'''Columns description:'''

* '''cat''' – category in tlayer (layer with turntable), which corresponds to both lines in turn

* '''ln_from''' – unique category in tucats layer assigned to the starting line of the turn

* '''ln_to''' – unique category in tucats layer assigned to the ending line line of the turn

* '''cost''' – cost for turn (integer or double)

* '''isec''' – point category in tucats layer, which represents the intersection, where the turn belongs

* '''angle''' – angle between the lines before and after the intersection (radians), positive -> turn to the right, negative -> turn to the left, 0 -> straight

[[Image:Turntable.png|center|800px|thumb]]

Every possible turn on any possible intersection is represented by unique record (line).
In the picture above you can see the turntable and part of vector layer with highlighted turn from the line with unique category 289 through the node (intersection) 561 to the line with unique category 234. In other words the given subject travels from intersection 564 through intersection 561 to intersection 527.

Arrows show orientation of each line. Note that in case of the line 289 the subject travels in BACKWARDS direction and therefore the In_from value is NEGATIVE (-289) while in case of the line 234 the travelling is in FORWARD direction, so the In_from value is POSITIVE (234).
The category of this turn can be seen in the cat column and the value is 1817 (this kind of category is stored in tlayer). This category value belongs only to the lines with unique category values 234 and 289 (stored in tuclayer).

In the angle column for this record the value is -1.373597 radians which is roughly -80°. This perfectly makes sense since left turns have negative values and right turns have positive. The angle is measured as deviance from straight direction (which is 0°).

== Specific parameters ==

* '''alayer''' - Name or number of the arc layer that will be expanded by turntable.

* '''tlayer''' - Name or number of the layer to which the turntable will be attached.

* '''tuclayer''' - Name or number of the layer with unique categories for every line and point. The points are placed on every node.

==WxGUI Vector Network Analysis Tool==

In GUI for v.net modules there is the checkbox option to “use turns”. If checked, it is required to fill these additional parameters: tlayer (layer with turntable), tuclayer (layer with unique categories for turntable). The dialog is shown below.

[[Image:Params_ttb.png|center|400px|thumb]]

It is possible to predefine costs for default or custom angle intervals in the Global settings dialog as shown in picture below.

[[Image:Global_ttb.png|center|400px|thumb]]

The angle, however, is only the simple one between two straight lines (from previous intersection to current node and from current intersection to the next one ignoring any original shorter polyline segments).
After the turntable is created, it is possible to customize costs explicitly for any specific turn on any given intersection (node) via the Local settings dialog.

[[Image:Local_ttb.png|center|400px|thumb]]

==Further Reading==

[ftp://ftp.geoinfo.tuwien.ac.at/winter/winter02modeling.pdf Modeling Costs of Turns in Route Planning]

[[Category:Documentation]]
[[Category:Vector]]
[[Category:Network Analysis]]