From OpenStreetMap Wiki
Jump to: navigation, search
Available languages — OpenRouteService
· Afrikaans · Alemannisch · aragonés · asturianu · azərbaycanca · Bahasa Indonesia · Bahasa Melayu · Bân-lâm-gú · Basa Jawa · Baso Minangkabau · bosanski · brezhoneg · català · čeština · dansk · Deutsch · eesti · English · español · Esperanto · estremeñu · euskara · français · Frysk · Gaeilge · Gàidhlig · galego · Hausa · hrvatski · Igbo · interlingua · Interlingue · isiXhosa · isiZulu · íslenska · italiano · Kiswahili · Kreyòl ayisyen · kréyòl gwadloupéyen · Kurdî · latviešu · Lëtzebuergesch · lietuvių · magyar · Malagasy · Malti · Nederlands · Nedersaksies · norsk bokmål · norsk nynorsk · occitan · Oromoo · oʻzbekcha/ўзбекча · Plattdüütsch · polski · português · română · shqip · slovenčina · slovenščina · Soomaaliga · suomi · svenska · Tiếng Việt · Türkçe · Vahcuengh · vèneto · Wolof · Yorùbá · Zazaki · српски / srpski · беларуская · български · қазақша · македонски · монгол · русский · тоҷикӣ · українська · Ελληνικά · Հայերեն · ქართული · नेपाली · मराठी · हिन्दी · অসমীয়া · বাংলা · ਪੰਜਾਬੀ · ગુજરાતી · ଓଡ଼ିଆ · தமிழ் · తెలుగు · ಕನ್ನಡ · മലയാളം · සිංහල · ไทย · မြန်မာဘာသာ · ລາວ · ភាសាខ្មែរ · ⵜⴰⵎⴰⵣⵉⵖⵜ · አማርኛ · 한국어 · 日本語 · 中文(简体)‎ · 吴语 · 粵語 · 中文(繁體)‎ · ייִדיש · עברית · اردو · العربية · پښتو · سنڌي · فارسی · ދިވެހިބަސް

OpenRouteService ( - short ORS) - Is much more than a website with a route service for cars, pedestrians and bicycles based on Open Standards and Open Geodata. Several Location Based Services (LBS) created from OSM data are available, developed by Pascal Neis. For example (Neis 2008):
  • Route Service
  • Geocoder/Reverse Geocoder
  • Directory Service
  • Accessibility Analysis Service
  • Emergency Route Service

Open Route Service
Screenshot of Open Route Service
Author: GIScience
Version: 24.1
License: Creative Commons Attribution-ShareAlike 2.0
Platform: Web

Easy to use, nice UI

General Information

ORS Coverage
Online since: April 2008
Developed by: Pascal Neis, further developed by Maxim Rylov, Enrico Steiger and others
Idea: Pascal Neis & Alexander Zipf
University of Heidelberg GIScience (Geoinformatics) Research Group ([1])
Currently supported Countries: Complete Europe, Asia, Africa, Australia, Oceania (routing and geocoder)

Worldwide: Directory Service (POI-search)]

Supported Languages for RouteInstructions (Route Service): see OpenRouteService/Instructions
API Interfaces
new Website on github[2] developed by: Timothy <ellersiek, Carina Lannig, Oliver Roick and others
Data updates by: (NEW update mechanism developed and deployed (06/2014) Enrico Steiger, Maxim Rylov, Lukas Loos,

05 06 ors roads.png

Report Feature Requests, General Feedback, Comments, Suggestions, Bugs or further questions via email to

What can you do on ORS? is much more than only a routing service: it uses a wide range of services based on OSM data that also could be used in other applications and scenarios. Currently the following services have been implemented within the frame of based on OSM data:

ORS Directory Service
  • The Directory Service is a service that provides access to an online directory to find the location of a specific or nearest place, product or service.
  • The Location Utility Service provides a Geocoder/Reverse Geocoder; the Geocoder transforms a description of a location, such as a place name, street address or postal code, into a normalized description of the location with a Point geometry.
ORS Route Service
  • The Route Service determines travel routes and navigation information according to diverse criteria. This has been realized for:
    • cars: fastest, shortest, recommended
    • several options to avoid tools, tunnels, etc.
    • same for heavy vehicles with many options
    • wheelchair routing (beta)
    • cars: use of realtime traffic (TMC), for GERMANY
    • bicycles (MTB, race bike, safest route...)
    • pedestrian
    • further extensions (particular options for different types of bicycles etc.) are planned or in work
ORS Accessibility Analysis Service
  • The Accessibility Analysis Service (AAS) calculates a polygon representing the area that is reachable within a certain time distance based on a street network around a given location.
ORS Emergency Route Service
  • In the Emergency Route Service you can specify areas that will be avoided by your route.
  • ...

Components of ORS

ORS Components.png

Components of ORS from Neis (2008)

Used OSM Tags for Routing

OSM Tags used for Car, Pedestrian and Bicycle Routing

Car Routing Pedestrian Routing Bicycle Routing
Key Value (km/h -> speed used in ORS) Key Value (km/h -> speed used in ORS) Key Value (km/h -> speed used in ORS)
highway motorway (110 km/h) & motorway_link (90 km/h), trunk (90 km/h) & trunk_link (70 km/h), primary (70 km/h) & primary_link (60 km/h), secondary (60 km/h) & secondary_link (50 km/h), tertiary (55 km/h) & tertiary_link (45 km /h), unclassified (50 km/h), residential (40km/h), living_street (10 km/h), service (30 km/h)* highway (trunk & trunk_link till october) primary & primary_link, secondary & secondary_link, tertiary & tertiary_link, unclassified, residential, living_street, service, track, pedestrian, cycleway*, footway, bridleway*, steps, path (on all ways 6 km/h) highway (trunk & trunk_link till october) primary & primary_link, secondary & secondary_link, tertiary & tertiary_link, unclassified, residential, living_street, service, track, cycleway, footway*, bridleway*, pedestrian*, path (on all ways 16 km/h)
access yes, no
motorcar yes, no foot yes, no bicycle yes, no
oneway yes, true, 1, no, false, -1 oneway yes, true, 1, no, false, -1
junction roundabout cycleway opposite, opposite_lane, opposite_track, track
route ferry route ferry route ferry
maxspeed (in work) only if the value is a number, e.g. '30'. '30 km/h' or similar are not supported! Further, only speeds between 5 and 130 km/h are used. mph will be transformed.
* if allowed

OSM Tags used for Wheelchair Routing

The wheelchair routing profile uses a mixture of static filtering, dynamic filtering and prioritisation.

  • Static Filtering means that OSM features having the listed tags are taken in or out of the routing graph independent of which preferences the users of the profile specify
  • Dynamic Filtering means that the OSM features having the listed tags are taken in or out of the routing graph dependent on which preferences the of the profile specify (such as, incline, surface/smoothness, height of dropped kerbs)
  • Prioritasation means that some OSM features having certain listed tags are getting higher (or lower) priority in route planning over other features, which may result in little detours in favour of a more suitable route

OSM Tags used for Static Filtering of Ways/Nodes Independent on User Preferences

The following table shows a list of tags that are used for static filtering. Depending on whether they are "accepted" or "non accepted", they are part of the graph or are completely taken out of the graph, independent on any user setting, and will NOT be available for any route computation. If they are "accepted" they will be available for any route computation.

Key Values for Accepted Ways Values for Non Accepted Ways
highway "footway", "pedestrian", "living_street", "residential", "unclassified", "service",

"trunk", "trunk_link", "primary", "primary_link", "secondary", "secondary_link", "tertiary", "tertiary_link", "road"

"path", "track"

"bridleway", "cycleway" (exception, if the way has the attributes bicycle/horse="designated", "official")

(on all ways 4 km/h)

"steps", "ford"

"trunk", "trunk_link", "primary", "primary_link", "secondary", "secondary_link", "tertiary", "tertiary_link", "road" (if explicitely tagged as sidewalk = "no"|"none")

route ("ferry", "shuttle_train"), public_transport("platform", railway ("platform") (for "ferry" 10km/h is set) foot|wheelchair = "no", "restricted", "private"
foot "yes", "designated", "official", "permissive", "limited" "no", "restricted", "private"
wheelchair "yes", "designated", "official", "permissive", "limited" "no", "restricted", "private"
sac_scale -- "hiking", "mountain_hiking", "demanding_mountain_hiking", "alpine_hiking", "demanding_alpine_hiking", "difficult_alpine_hiking"
motorroad "no", (exception, if the way has the attributes sidewalk = "yes", "both", "right", "left") "yes"
bicycle|horse all other values "designated", "official"
sidewalk "yes", "right", "left", "both" "no" (exception for highway = "footway", "pedestrian", "living_street", "residential", "unclassified", "service"
Key Values for Accepted Nodes Values for Non Accepted Nodes
barrier "gate", "bollard", "lift_gate", "cycle_barrier", "entrance", "cattle_grid", "swing_gate", "chain", "bump_gate" (exception, if locked = "yes" "fence", "wall", "hedge", "retaining wall", "city_wall", "ditch", "hedge_bank", "guard_rail", "wire_fence", "embankment"

"stile", "block", "kissing_gate", "turnstile", "hampshire_gate"

OSM Tags applied for Dynamic Filtering of Way/Nodes Depending On User Preferences

The following features are accepted/not accpeted depending on the preferences the users set in the User Interface of OpenRouteService.


For the keys surface and smoothness following logic applies for sidewalks:

If sidewalk=left|both|right exists, evaluate whether also "sidewalk:surface:left", "sidewalk:surface:both", "sidewalk:surface:right", "sidewalk:smoothness:left", "sidewalk:smoothness:both", "sidewalk:smoothness:right" exist. If so use these values for surface and smoothness of the sidewalks, if not fall back to surface and smoothness of the way, even for the sidewalks

Key route option "concret, asphalt" route option "flattened cobblestone and better" route option "cobblestone and better" route option "compacted" all traversable surfaces

(also: sidewalk:left|both|right:surface)

"paved", "asphalt", "concrete" "paving_stones", "concrete_plates", "cobblestone:flattened" (+better) "concrete:lanes", "cobblestone" (+better) "unpaved", "fine_gravel", "compacted" "metal", "ice", "grass_paver", "sand", "dirt", "earth", "grass", "gravel", "ground", "mud", "pebblestone", "salt", "snow", "wood", "woodchips"

(also: sidewalk:left|both|right:smoothness)

"excellent", "good" "excellent", "good" "intermediate" (+better) "bad" (+better) "bad" (+better)
tracktype "grade1" "grade1" "grade1" "grade2" (+better) "grade4" (+better)
Key route option "up to 3%" route option "up to 6%" route option "up to 9%" route option "up to 12%" all inclines
incline incline <= 0.03 incline <= 0.06 incline <= 0.09 incline <= 0.12 incline <= 0.31

(note: due to a restriction of attribute storage all incline values > 0.31 are mapped to 0.31)

The values "up", "down" and "yes" are mapped to incline = 0.1

The value "steep" is mapped to incline = 0.15

The value "no" is mapped to incline = 0

Key route option "up to 3cm" route option "up to 6cm" route option "up to 10cm" route option "any"
kerb:height kerb:height <= 0.03 kerb:height <= 0.06 kerb:height <= 0.10 kerb:height <= 0.15

(note: due to a restriction of attribute storage all kerb:height values > 0.15 are mapped to 0.15)

kerb "lowered", "yes", "flush", "unknown", "dropped", "rolled" (+better) (+better) "none", "raised", "no" (+better)
sloped_curb "yes", "both", "at_grade", "flush", "low" (+better) (+better) "no", "one" (+better)
curb "lowered", "flush;lowered", "sloped", "lowered_and_sloped", "flush", "flush_and_lowered" (+better) (+better) "regular", "none", (+better)

The values "at_grade", "flush", "flush;lowered" and "flush_and_lowered" are mapped to kerb:height = 0.0

The values "yes", "both", "low", "lowered", "dropped", "rolled", "sloped" and "lowered_and_sloped" are mappend to kerb:height = 0.03

The values "no", "one", "raised", "none" and "regular" are mapped to kerb:height = 0.15

Key route option "up to 3cm" route option "up to 6cm" route option "up to 10cm" route option "any"
kerb:height kerb:height <= 0.03 kerb:height <= 0.06 kerb:height <= 0.10 kerb:height <= 0.15

(note: due to a restriction of attribute storage all kerb:height values > 0.15 are mapped to 0.15)

kerb "lowered", "yes", "flush", "unknown", "dropped", "rolled" (+better) (+better) "none", "raised", "no" (+better)
sloped_curb "yes", "both", "at_grade", "flush", "low" (+better) (+better) "no", "one" (+better)
curb "lowered", "flush;lowered", "sloped", "lowered_and_sloped", "flush", "flush_and_lowered" (+better) (+better) "regular", "none", (+better)

The values "at_grade", "flush", "flush;lowered" and "flush_and_lowered" are mapped to kerb:height = 0.0

The values "yes", "both", "low", "lowered", "dropped", "rolled", "sloped" and "lowered_and_sloped" are mappend to kerb:height = 0.03

The values "no", "one", "raised", "none" and "regular" are mapped to kerb:height = 0.15

OSM Tags used for Prioritisation/Weighting of Features Indpendent of User Preferences

Ways (and also some nodes) get higher weights (positive prioritisation) as well as lower weights (negative prioritisation) depending on their tags. Also combinations of positive and negative features are possible. Segments that have higher weights are more probably to be used in the wheelchair routing.

Key Positive Prioritisation Negative Prioritisation
tunnel "yes"
sidewalk "yes", "both", "right", "left"
foot "designated", "yes", "official", "permissive", "limited"
bicycle "official"
highway "footway", "pedestrian", "living_street", "crossing" "path", "track" (if no further information about surface|smoothness|incline|tracktype is available)

"trunk", "trunk_link", "primary", "primary_link", "secondary", "secondary_link", "tertiary", "tertiary_link", "road (if no sidewalk is tagged)

maxspeed if maxspeed > "50"
footway "crossing"

Further Routing Profiles/Applications

additional project on adding wheelchair routing:

it is also used for haiti emergency routing:


Please help to improve the Instructions and the many translations! (ca. 40 languages and dialects supported so far!)

Route Service Comparison Matrix

A comparison matrix is available at Routing/OnlineRouters#Route service comparison matrix

Evaluation of data fitness for routing

ORS hits, route requests and failures due to errors in street network over the course of time (Schmitz, Zipf & Neis (2008))

OpenRouteService API

The functioning of the API has changed. For the current status visit our documentation.

OpenLS Services Status 01.09.2015
Description: Through the OpenLS interface requests can be generated to the appropriate services without further query limitations. The offered API's are only valid for ' one ' year.

In case you plan a long-term use of the interfaces within your projects or high volume or for commercial applications , please contact openrouteservice AT

OpenLS Routing Services*
Restful Webservice route request:
testclient with meta information and schema file for routing service:
direct route request via URL + parameter:
graph routing profile update information:
*currently the maximum request limitation is 1000/hour and user. We kindly ask you to not use the service excessively. In case the server performance will be affected we reserve us the right to block individual service user.
OpenLS Geocoding Service
Restful Webservice geocode request:
testclient with meta information and schema file for geocoding service:
direct geocoding route request via URL + parameter:
OpenLS Directory (POI Search) Service
Restful Webservice directory request:
testclient with meta information and schema file for directory service:
direct directory request via URL + parameter:
OpenLS Acessbility Analysis service*
Restful Webservice accessbility analysis request:
testclient with meta information and schema file for analysis service:
direct accesbility analysis request via URL + parameter:
*for performance reasons only 30 minutes are currently supported

Direct Routing Request (via GET)

  • start = longitude and latitude of the start position, e.g. '7.0892567,50.7265543'
  • via (optional) = longitudes and latitudes of the via positions separated by blank, e.g. '7.0920891,50.7295968 7.1044487,50.7247613 7.1049637,50.7298142'
  • end = longitude and latitude of the end position, e.g. '7.0986258,50.7323634'
  • routepref = the preference of the routing: 'Car', 'Pedestrian', 'Bicycle', 'BicycleSafety', 'BicycleRacer','BicycleTour', 'BicycleMTB','HeavyVehicle', 'Wheelchair'
  • weighting = the preference of the routing method: 'Fastest', 'Shortest', 'Recommended'
  • distunit = distance unit of route calculation (default in kilometer 'KM', meters 'M', miles 'MI')
  • noMotorways = Avoid Motorways? e.g. 'noMotorways=false' OR 'noMotorways=true'
  • noTollways = Avoid Tollways? e.g. 'noTollways=false' OR 'noTollways=true'
  • noFerries = Avoid Ferrys? e.g. 'noFerries=false' OR 'noFerries=true'
  • noUnpavedroads (only for Bicycle profile) = Avoid unpaved Roads? e.g. 'noUnpavedroads=false' OR 'noUnpavedroads=true'
  • noSteps (only for Bicycle profile) = Avoid Steps? e.g. 'noSteps=false' OR 'noSteps=true'
  • instructions = Route instructions 'instructions=true' or 'instructions=false'
  • lang = language of route instructions: 'de' (Deutsch), 'en' (English), 'it' (Italiano), 'fr' (Français), 'es' (Español), 'pt' (Portugese), 'nl' (Nederlands) etc., all supported languagse see here[3]
  • maxspeed specify the maximum speed in km/h for the selected route profile e.g. 'maxspeed=10' see Key:maxspeed

additional Parameter only for HeavyVehicle route profile

  • hazardous = hazardous material? e.g. 'hazardous=false' OR 'hazardous=true' , further info see here[4]
  • value_weight = maximum weight restriction in tons
  • value_height = maximum height restriction in meter
  • value_length = maximum length restriction in meter
  • value_axleload = maximum axleload restriction in tons

optional Parameters only Bicycle route profile

  • elevation = retrieve elevation information for each waypoint (in meters above NHN)? e.g. 'elevation=true' OR 'elevation=false' 
  • surface = retrieve way and surface information? e.g. 'surface=true' OR 'surface=false' -> feature requires 'instruction=true'

Response surface list {Unknown = 0, Paved = 1, Unpaved = 2, Asphalt = 3, Concrete = 4, Cobblestone = 5, Metal = 6, Wood = 7, CompactedGravel = 8, FineGravel = 9, Gravel = 10, Dirt = 11, Ground = 12,  Ice = 13, Salt = 14, Sand = 15, Woodchips = 16, Grass = 17,  GrassPavel = 18 }

Response waytype list {Unknown = 0, StateRoad = 1, Road = 2, Street = 3, Path = 4, Track = 5, Cycleway = 6, Footway = 7, Steps = 8, Ferry = 9, Construction = 10}

Example URL

URL + Parameter:
Bicycle & Shortest path:,49.240011&end=9.156506,49.230011&via=&lang=de&distunit=KM&routepref=Bicycle&weighting=Shortest&avoidAreas=&useTMC=false&noMotorways=false&noTollways=false&noUnpavedroads=false&noSteps=false&noFerries=false&instructions=false

Bicycle & Shortest path + Elevation and surface information:,49.240011&end=9.156506,49.230011&via=&lang=de&distunit=KM&routepref=Bicycle&weighting=Shortest&avoidAreas=&useTMC=false&noMotorways=false&noTollways=false&noUnpavedroads=false&noSteps=false&noFerries=false&elevation=true&surface=true&instructions=true
Car & Fastest path:,49.240011&end=8.72083,49.7606&via=&lang=de&distunit=KM&routepref=Car&weighting=Fastest&avoidAreas=&useTMC=false&noMotorways=false&noTollways=false&noUnpavedroads=false&noSteps=false&noFerries=false&instructions=true
Heavy Vehicle & Fastest path:,49.240011&end=8.72083,49.7606&via=&lang=de&distunit=KM&routepref=HeavyVehicle&weighting=Fastest&noMotorways=false&noTollways=false&noUnpavedroads=false&noSteps=false&noFerries=false&instructions=false&value_length=15&value_height=4&value_weight=7&value_width=4&value_axleload=2&hazardous=true

Direct Geocoding Request (via GET)

  • FreeFormAdress = free text search of address
  • MaxResponse = maximum amount of search results
  • lang = language of Reverse Geocode response (default 'de'), 'de' (Deutsch), 'en' (English), 'it' (Italiano), 'fr' (Français), 'es' (Español), 'pt' (Portugese), 'nl' (Nederlands) etc., all supported languagse see here[5]
  • lon = longitude
  • lat = latitude
Example URL

URL + Parameter:,%20Meckenheimer%20Allee&MaxResponse=20

URL + Parameter + Lang:,%20Meckenheimer%20Allee&MaxResponse=20&lang=en

URL + Parameter :

Direct Accesibility Analysis Request (via GET)

  • position (lon/lat) = longitude and latitude of the position marker, e.g. '-0.12772,51.50715'
  • routePreference = preferred route profile: 'Car', 'Bicycle', 'Pedestrian', 'HeavyVehicle'
  • method = method of isochrones generation: 'RecursiveGrid', 'TIN'
  • interval= interval of isochrones generation (in minutes): '180'
Example URL

URL + Parameter:,49.42859632294706&minutes=1&routePreference=Car&method=RecursiveGrid&interval=180

URL + Parameter:,49.42859632294706&minutes=1&routePreference=Bicycle&method=TIN&interval=180


In order to show just the map in a certain position and zoom level you may skip the start and end parameters and use the permalink parameters.

  • pos (lon/lat) = longitude (centre of the map),latitude (centre of the map)
  • zoom = zoom level
  • layer(optional) = default background layer (OpenMapsurfer=B000, OSM-WMS worldwide=0B000, OSM Mapnik=00B00, Stamen Map=0000B, OpenCycleMap=000B0)

Example URL
URL + Parameter:,52.27606884292058&zoom=13&layer=B0000


In order to show the map with a calculated route result use the same parameters then for routing.

  • pos (lon/lat) = longitude and latitude of the position marker, e.g. '-0.12772,51.50715'
  • zoom = zoom level
  • layer(optional) = default background layer (OpenMapsurfer=B0000, OSM-WMS worldwide=0B000, =B0000OSM Mapnik=00B00, OpenCycleMap=000B0, Stamen Map=0000B)
  • routeWeigh = weighting method of routing: 'Fastest', 'Shortest','Recommended'
  • routeOpt = preferred route profile: 'Car', 'Bicycle','Pedestrian','HeavyVehicle'
  • routeLang = language of the route instructions: 'de' (Deutsch), 'en' (English), 'it' (Italiano), 'fr' (Français), 'es' (Español) etc., all supported languagse see here[6]
  • lang = language of the ORS menu: 'de' (Deutsch), 'en' (English), 'it' (Italiano), 'fr' (Français), 'es' (Español) etc. all suported menu languages see here[7]
  • distUnit = distance unit of route calculations, default meters (m)

Example URL

Supported Webbrowsers

Browser Firefox Opera Safari InternetExplorer Google Chrome
Versions Linux 31 ESR
Linux 33
Win 31 ESR
Win 33
Linux 9.63
Linux 10 alpha
Win 9.63
Win 10 alpha
Win 3.2.1
Win 4 beta
Win 7.0.5730.11 Win
Search Yes Yes Yes Yes Yes
Map Interaction Yes Yes Yes Yes Yes
Routing Yes Yes Yes Yes Yes
AvoidAreas Yes Partial* Partial* Partial* Yes
POI Yes Yes Yes Yes Yes
Accessibility Analysis Yes Yes Yes Yes Yes
  • Currently there are only problems with the deletion of AvoidAreas.

Optimized for resolution 1280x1024 or higher.

User Manual Help



  • The OpenRouteService doesn't interpret OSM Relation:restrictions, which can be a severe limit to the usefulness for traffic routing in some cities. This route is incorrect for example, because the a turn restriction relation is in place shown on this map.
  • Clicking the map often leads to an unintentional change in the start or end location marker.
  • Barriers are not taken into credit. Try a route between the two towns Bremm and Dohr. OpenRouteservice would give you the former road which is still accessible but with a barrier that you can't pass with the car. YourNavigation takes the mapped barrier into credit and takes the far longer road (which is the shortest road for cars for about 5 years now) if you choose car navigation. Can somebody please add the recognition of barriers into OpenRouteService.
  • Ways tagged with construction=* or proposed=* are not taken into credit. See for example [8]. This is bad if the map is not up to date. Possible solution: additional permanent RouteLink which enables it. These tags are deprecated.
  • Another example which does not route the shortest way: [9]
  • Example where pedestian routing works well: [10], but the designated cycleway is ignored [11] when routing for bicycles.


Papers related to OpenRouteService, OpenLS+OSM in some of our applications and projects: cmp.:

  • Steiger, E. and Zipf, A.(2015): Enriching OSM road networks with TMC LCL information. RICH-VGI: enRICHment of volunteered geographic information (VGI): Techniques, practices and current state of knowledge. 18th AGILE Conference on Geographic Information Science. Lisbon, Portugal.
  • Barron, C., Neis, P. & Zipf, A. (2013): A Comprehensive Framework for Intrinsic OpenStreetMap Quality Analysis. , Transactions in GIS, DOI: 10.1111/tgis.12073.
  • Ballatore, A. and Zipf, A. (2015): A Conceptual Quality Framework for Volunteered Geographic Information. COSIT - CONFERENCE ON SPATIAL INFORMATION THEORY XII. October 12-16, 2015. Santa Fe, New Mexico, USA. Lecture Notes in Computer Science, pp. 1-20.
  • Neis, A. & Zielstra, D. (2014): Generation of a tailored routing network for disabled people based on collaboratively collected geodata. Applied Geography. Vol. 47, pp. 70–77.
  • Neis, P. (2014): Measuring the Reliability of Wheelchair User Route Planning based on Volunteered Geographic Information. Transactions in GIS.
  • Goetz, M. & Zipf, A. (2012): Using Crowdsourced Indoor Geodata for Agent-Based Indoor Evacuation Simulations. ISPRS International Journal of Geo-Information. Vol.1(2), pp.186-208. MDPI. DOI:10.3390/ijgi1020186.
  • Neis, P. & Zipf, A. (2012): Analyzing the Contributor Activity of a Volunteered Geographic Information Project – The Case of OpenStreetMap. ISPRS International Journal of Geo-Information. Vol.1(2), pp.146-165. MDPI. DOI:10.3390/ijgi1020146 .
  • Steiger, E. Zipf, A.(2015): Erstellungs eines OSM Graphen mit TMC LCL Informationen In: Strobl, J., Blaschke, T., Griesebner, G. (Hrsg.): Angewandte Geoinformatik 2015. Berlin
  • Neis, P., Zielstra, D. & Zipf, A. (2012): The Street Network Evolution of Crowdsourced Maps - OpenStreetMap in Germany 2007-2011. Future Internet. Special Issue "NeoGeography and WikiPlanning" (Eds: B. Murgante, G. Borruso, M. Gibin), Vol.4, pp.1-21 (DOI 10.3390/fi4010001). ISSN 1999-5903.
  • Sun, Y., Fan, H., Bakillah, M. & Zipf, A. (2013): Road-based Travel Recommendation Using Geo-tagged Images. Computers, Environment and Urban Systems (CEUS). Elsevier.
  • Neis, P., Zielstra, D. & Zipf, A. (2013): Comparison of Volunteered Geographic Information Data Contributions and Community Development for Selected World Regions. Future Internet. Vol. 5, pp. 282-300.
  • Goetz, M. & Zipf, A. (2011): Formal Definition of an User-adaptive and Length-optimal Routing Graph for Complex Indoor Environments. Geo-spatial Information Science (GSIS). Vol.14(2). Springer.
  • John, S., Hahmann, S., Zipf, A. (2015): Automatisierte Ableitung des Gefälles von Straßen und Wegen aus OpenStreetMap GPS-Tracks. 59. Deutscher Kongress für Geographie (DKG 2015). Berlin, Germany. (accepted as presentation).
  • Neis, P. and Zipf, A. (2008): Generating 3D Focus Maps for the (mobile) Web - an interoperable approach. In: International Journal of Location Based Services (JLBS). Vol. 2, Issue 2.
  • Neis, P. and Zipf, A. (2007): Realizing Focus Maps with Landmarks using OpenLS Services. 4th International Symposium on LBS and Telecartography 2007. Hongkong.
  • Neis, P., A. Zipf, R. Helsper, Kehl, A. (2007): Webbasierte Erreichbarkeitsanalyse - Vorschläge zur Definition eines Accessibility Analsysis Service (AAS) auf Basis des OpenLS Route Service. REAL CORP 2007. Wien, Austria.
  • Schmitz S., Zipf A. and Neis P. (2008): New Applications based on Collaborative Geodata - the Case of Routing. XXVIII INCA International Congress on Collaborative Mapping and SpaceTechnology, Gandhinagar, Gujarat, India
  • Neis P. and A. Zipf (2008): LBS_2.0 - Realisierung von Location Based Services mit user-generated, collaborative erhobenen freien Geodata. In: J. Roth (Hrsg.): 5. GI/ITG KuVS Fachgespräch Ortsbezogene Anwendungen und Dienste, 4.-5. September 2008, Nürnberg. Sonderdruck Schriftenreihe der Georg-Simon-Ohm-Hochschule Nürnberg Nr. 42, ISSN 1867-5433
  • Schmitz, S., Zipf, A. and Pascal Neis (2008): Proposal to define common resources for OpenGIS Location Services. 5th International Symposium on LBS & TeleCartography. Salzburg. Austria.
  • Haase M., A. Zipf , P. Neis , V. de Camargo (2008): Interoperable Routing Services in the Context of Evacuation Schemes due to Urban Flooding. EnviroInfo 2008 Conference. Environmental Informatics and Industrial Ecology. Lueneburg, Germany.
  • Neis, P., Zipf, A (2008): is three times “Open”: Combining OpenSource, OpenLS and OpenStreetMaps. Accepted for: GIS Research UK (GISRUK 08). Manchester.
  • Brinkhoff,T., M. BERTLING, J. BIERMANN, T. GERVENS, R. KÖNIG, D. KÜMPER, P. NEIS, B. STOLLBERG, C. ROLFS, A. WEISER, J. WEITKÄMPER, A. ZIPF (2008): Offenes Katastrophenmanagement mit freiem GIS Zur interoperablen Kopplung von Leitstellensystem, mobilen Clienten und GDI mit Prozessierungsdiensten. AGIT 2008. Symposium für angewandte Geoinformatik. Salzburg. Austria.
  • Weiser, A., P. Neis, A. Zipf (2006): Orchestrierung von OGC Web Diensten im Katastrophenmanagement - am Beispiel eines Emergency Route Service auf Basis der OpenLS Spezifikation. In: GIS - Zeitschrift für Geoinformatik. 09/2006. pp. 35-41.
  • Neis, P. und Zipf, A. (2008): OpenStreetMap – Grundlagen und Potentiale der freien Wiki-Weltkarte. GIS Report 2008/2009. Harzer Verlag. Karlsruhe.
  • Neis, P. und Zipf, A. (2008): LBS 2.0 mit - die OpenGIS-konforme Routing-Plattform auf Basis der freien Geodaten von OpenStreetMap. GIS Report 2008/2009. Harzer Verlag. Karlsruhe.
  • Neis, P., A. Schilling, A. Zipf (2007): 3D Emergency Route Service (3D-ERS) based on OpenLS Specifications. GI4DM 2007. 3rd International Symposium on Geoinformation for Disaster Management. Toronto, Canada.
  • Neis, P., A. Zipf (2007): A Web Accessibility Analysis Service based on the OpenLS Route Service. AGILE 2007. International Conference on Geographic Information Science of the Association of Geograpic Information Laboratories for Europe (AGILE). Aalborg, Denmark.
  • Bauer, M., P. Neis, C. Weber, A. Zipf (2007): Kontextabhängige Landmarken für mobile 3D Navigationsanwendungen. In: 4. Fachgespräch: Ortsbezogene Anwendungen und Dienste. LMU München.