I hava two questions.First : after reading the code of map-matching about the strategy of generated for type and value for 'Node' , i.e the file OSMReader.java the function boolean addNode(ReaderNode node) ,when is the type of Node created ? Second:OSMReader.java the function: Collection addOSMWay(final TLongList osmNodeIds, final long flags, final long wayOsmId) , i don't understand the purpose of internalNodeID ‘tmpNode’ in different internal （i.e : tmpNode > -TOWER_NODE）, looking forward your reply , thanks sincerely !

## Technical Overview of GraphHopper
To get a better understanding also take a look in the source code, especially in the unit tests and in
some resources we [published](http://karussell.wordpress.com/2014/01/23/graphhopper-news-article-in-java-magazine-and-fosdem-2014/)
or [here](http://graphhopper.com/public/slides/).
There are mainly three parts:
### 1. Data Import
The default import is done via OSMReader which imports OpenStreetMap data. You can configure it via API
or use the `graphhopper.sh` script which utilizes the config.properties where you can specify if it should
read `car`, `foot` or all vehicles at once. You'll have to make sure that you allocate enough memory for your
specific graph (E.g. ~2GB for Germany) e.g. `export JAVA_OPTS="-Xmx2g"`. The import process is fast e.g.
complete Germany takes roughly 10 minutes. Additionally it will take time if you choose
`prepare.ch.weightings=fastest` in the config.properties which will dramatically improve query time
but requires more RAM on import.
### 2. The Graph

## Low level API
If you just start to use GraphHopper please refer to [routing docs](./routing.md)
or [the quickstart for developers](./quickstart-from-source.md)
and come back here later if the higher level API does not suit your needs.
### What are pillar and tower nodes?
From road network sources like OpenStreetMap we fetch all nodes and create the routing graph but
only a sub-set of them are actual junctions, which are the ones we are interested in while routing.
Those junction nodes (and end-standing nodes of dead alleys) we call *tower nodes* which also
have a graphhopper node ID associated, going from 0 to graph.getNodes().
The helper nodes between the junctions we call 'pillar nodes' which can be fetched via
`edgeIteratorState.fetchWayGeometry(0)`. Avoiding the traversal of pillar nodes while routing makes
routing a lot faster (~8 times).
That splitting into pillar and tower nodes is also the reason why there can't be a unique mapping from
one OSM node ID to exactly one GraphHopper node ID. And as one OSM Way is often splitted into multiple
edges the same applies for edge IDs too.