Help with LINZ Runways
Glen Barnes
Chatham Islands.
We uploaded this file for the runways - http://gist.github.com/351267
and you can see the result here for a single 'airstrip' http://osm.org/go/EAmKCwP2
and here for the airport and the runway http://osm.org/go/EAnEdSTF--
(the airport was file is http://gist.github.com/351279)
A couple of things:
1) The runways don't seem to be showing on the map. I think they need
to be straight ways and not polygons?
2) Do we need to 'link' the runway to the airport in someway?
Any feedback would be good.
Rob Coup has written a tool to handle the mapping of LINZ data to OSM
types - If anyone else is keen to have a go at mapping some of the
other LINZ layers then let me know and I can add you to the user list.
just drop me an email - glen [at] open [dot] org [dot] nz. I'm away
this weekend so won't have much internet access but can add you next
week.
Robin Paulson
> I've had a go at mapping the runways and airports from LINZ for the
> Chatham Islands.
>
> We uploaded this file for the runways - http://gist.github.com/351267
>
> and you can see the result here for a single 'airstrip' http://osm.org/go/EAmKCwP2
>
> and here for the airport and the runway http://osm.org/go/EAnEdSTF--
> (the airport was file is http://gist.github.com/351279)
>
> A couple of things:
>
> 1) The runways don't seem to be showing on the map. I think they need
> to be straight ways and not polygons?
> 2) Do we need to 'link' the runway to the airport in someway?
you've not actually tagged the lines with an airport tag - at the
moment it's tagged as a relation, which won't show on the usual
renderers. why did you choose the multiploygon, inner/outer relation.
that's usually used for things with holes in
which tags were you aiming to use? you might want to try aeroway=runway
you don't need to link it with anything
and be aware, it's generally frowned upon to 'tag for the renderer',
i.e. all you need to do is add the correct tags, and don't worry if it
shows on the map. the main concern is that it is in the database in a
useful way
Robin Paulson
> you've not actually tagged the lines with an airport tag - at the
> moment it's tagged as a relation, which won't show on the usual
> renderers. why did you choose the multiploygon, inner/outer relation.
> that's usually used for things with holes in
Hamish
> I've had a go at mapping the runways and airports from LINZ for the
> Chatham Islands.
> Any feedback would be good.
>
> Rob Coup has written a tool to handle the mapping of LINZ data to OSM
> types - If anyone else is keen to have a go at mapping some of the
> other LINZ layers then let me know and I can add you to the user list.
> just drop me an email - glen [at] open [dot] org [dot] nz. I'm away
> this weekend so won't have much internet access but can add you next
> week.
this one?
http://svn.openstreetmap.org/applications/utils/import/linz2osm/mp2osm_linz_jr.py
note 'landuse': 'aeroway'
If possible please provide links and quick step 1,2,3,4 for the
process for us clueless beginners!
thanks,
Hamish
Robin Paulson
> this one?
> http://svn.openstreetmap.org/applications/utils/import/linz2osm/mp2osm_linz_jr.py
>
> note 'landuse': 'aeroway'
there's a landuse=aeroway? jesus, there's some redundant junk on osm
i think this is more useful as a guide how to map airports:
Hamish
>> this one?
>> http://svn.openstreetmap.org/applications/utils/import/linz2osm/mp2osm_linz_jr.py
>>
>> note 'landuse': 'aeroway'
Robin:
> there's a landuse=aeroway? jesus, there's some redundant junk on osm
AFAIK the key:value set is open & without bounds. Only mob discipline
holds things consistent.
> i think this is more useful as a guide how to map airports:
> http://wiki.openstreetmap.org/wiki/Key:aeroway
It is possible that Joe's python import script (above) can be further
refined to more closely reflect the modern tagging conventions.
Hamish
Robin Paulson
> AFAIK the key:value set is open & without bounds. Only mob discipline
> holds things consistent.
you would be correct there. i used to be involved (trying to) clean
up/introduce sanity into/remove duplicate tags in osm; an almost
sisyphean task http://en.wikipedia.org/wiki/Sisyphus
Glen Barnes
On Apr 1, 4:15 pm, Robin Paulson <robin.paul...@gmail.com> wrote:
> On 1 April 2010 16:05, Glen Barnes <barnaclebar...@gmail.com> wrote:
>
>
> you've not actually tagged the lines with an airport tag - at the
> moment it's tagged as a relation, which won't show on the usual
> renderers. why did you choose the multiploygon, inner/outer relation.
> that's usually used for things with holes in
>
> which tags were you aiming to use? you might want to try aeroway=runway
Right - So I know tagged the way with aeroway=runway and it is still
not showing - http://osm.org/go/EAmKCZH9
I see what you are saying about don't tag to the renderer but we still
want to make sure we are doing it correctly so that it actually shows
on the main OSM site. We want to make sure we get all of the Chatham
layers imported as best we can so that when we do other parts of the
country it looks OK.
Any chance someone can see if the can get the runway viewable at the
above link?
Glen Barnes
break down things pretty well and has a GUI tag scripting thing. It
will have to wait until next week for instructions as I'm away for the
long weekend.
Glen
On Apr 1, 6:04 pm, Hamish <hamish.bow...@gmail.com> wrote:
> Glen wrote:
> > I've had a go at mapping the runways and airports from LINZ for the
> > Chatham Islands.
> ...
> > Any feedback would be good.
>
> > Rob Coup has written a tool to handle the mapping of LINZ data to OSM
> > types - If anyone else is keen to have a go at mapping some of the
> > other LINZ layers then let me know and I can add you to the user list.
> > just drop me an email - glen [at] open [dot] org [dot] nz. I'm away
> > this weekend so won't have much internet access but can add you next
> > week.
>
> this one?http://svn.openstreetmap.org/applications/utils/import/linz2osm/mp2os...
Robin Paulson
> Right - So I know tagged the way with aeroway=runway and it is still
> not showing - http://osm.org/go/EAmKCZH9
maybe wait a while for it to render
check this:
http://www.openstreetmap.org/?lat=-37.01079&lon=174.78576&zoom=16
Robin Paulson
>> I see what you are saying about don't tag to the renderer but we still
>> want to make sure we are doing it correctly so that it actually shows
>> on the main OSM site. We want to make sure we get all of the Chatham
hmm, possibly. i think we'll be ok if most of the data shows. if some
doesn't render, it won't be a biggie. to be honest, you don't want all
the data rendering on one site, it gets so busy. there are other
sites, which show the data relevant to their focus (e.g. cycling,
hiking, marine, etc.)
>> layers imported as best we can so that when we do other parts of the
>> country it looks OK.
>>
>> Any chance someone can see if the can get the runway viewable at the
>> above link?
it's working now. the problem was the loop - runways are expected to
be a line, not a closed polygon. i broke the polygon into two pieces,
and it works ok now. was the line drawn in a loop to represent the
edge of a straight runway, or because there is actually a closed loop
of runway there?
Hamish
> it's working now. the problem was the loop - runways are expected to
> be a line, not a closed polygon.
right, http://wiki.openstreetmap.org/wiki/Key:aeroway shows the runway
"Element" as a polyline and not an area.
so to tag the polygon as aeroway=aerodrome and/or draw a line up the
middle of the polygon and tag it aeroway=runway?
(and so runway width is left up to renderer to choose instead of taken
from data)
> i broke the polygon into two pieces,
> and it works ok now. was the line drawn in a loop to represent the
> edge of a straight runway, or because there is actually a closed loop
> of runway there?
I don't know for sure, but I somehow doubt Pitt Island has more than a
grass strip. :) I think you can be pretty comfortable that LINZ
provides runway polygons and OSM wants a line in this case.
fwiw, from your AKL url,
http://www.openstreetmap.org/?lat=-37.01079&lon=174.78576&zoom=16
-Export tab-
[*] OpenStreetMap XML Data
Save As... AKL_airport.osm
$ grep 'tag' AKL_airport.osm | sort | uniq
<tag k="aeroway" v="aerodrome"/>
<tag k="aeroway" v="apron"/>
<tag k="aeroway" v="runway"/>
<tag k="aeroway" v="taxiway"/>
<tag k="aeroway" v="terminal"/>
<tag k="amenity" v="parking"/>
<tag k="building" v="yes"/>
<tag k="created_by" v="Potlatch 0.9c"/>
<tag k="created_by" v="Potlatch alpha"/>
<tag k="highway" v="bus_stop"/>
<tag k="highway" v="primary"/>
<tag k="highway" v="service"/>
<tag k="highway" v="unclassified"/>
<tag k="iata" v="AKL"/>
<tag k="icao" v="NZAA"/>
<tag k="is_in" v="Auckland,North Island,New Zealand"/>
<tag k="junction" v="roundabout"/>
<tag k="landuse" v="grass"/>
<tag k="name" v="Airbus"/>
<tag k="name" v="Auckland International"/>
<tag k="name" v="Domestic Terminal"/>
<tag k="name" v="International Terminal"/>
<tag k="name" v="Ray Emery Drive"/>
<tag k="oneway" v="yes"/>
<tag k="operator" v="Airbus"/>
<tag k="place" v="airport"/>
<tag k="ref" v="AIR"/>
<tag k="route" v="bus"/>
<tag k="source" v="Gagravarr_Airports"/>
<tag k="type" v="civil"/>
<tag k="type" v="route"/>
Robin Paulson
> so to tag the polygon as aeroway=aerodrome and/or draw a line up the
> middle of the polygon and tag it aeroway=runway?
> (and so runway width is left up to renderer to choose instead of taken
> from data)
well, an airport and a runway are two different things of course.
if the data you are importing is an airport, it should be tagged as an
airport, if it's a runway, it should be tagged as a runway. without
seeing that data in the context of everything else round there/other
airports in the data set, it's hard to say what they were trying to
indicate in the LINZ data
could you look at the LINZ data for auckland airport? that might give
us some more context
>> i broke the polygon into two pieces,
>> and it works ok now. was the line drawn in a loop to represent the
>> edge of a straight runway, or because there is actually a closed loop
>> of runway there?
>
> I don't know for sure, but I somehow doubt Pitt Island has more than a
> grass strip. :) I think you can be pretty comfortable that LINZ
> provides runway polygons and OSM wants a line in this case.
not necessarily - LINZ could well include the entire airfield as an area
> fwiw, from your AKL url,
> http://www.openstreetmap.org/?lat=-37.01079&lon=174.78576&zoom=16
> -Export tab-
> [*] OpenStreetMap XML Data
> Save As... AKL_airport.osm
>
> $ grep 'tag' AKL_airport.osm | sort | uniq
yep. has that helped with how airports are tagged in osm? can you
adjust the LINZ import rules to tag things appropriately?
Hamish
> well, an airport and a runway are two different things of course.
>
> if the data you are importing is an airport, it should be tagged as an
> airport, if it's a runway, it should be tagged as a runway. without
> seeing that data in the context of everything else round there/other
> airports in the data set, it's hard to say what they were trying to
> indicate in the LINZ data
>
> could you look at the LINZ data for auckland airport? that might give
> us some more context
looking at the LINZ layers at Koordniates.com there are a few:
http://koordinates.com/layers/category/air-aviation/
* runways/airstrips (vector polygons)
* airports (vector polygons)
* helipads (points)
the descriptions at the above weblink are pretty clear about what they show.
see the main chatham airport.. both runway polygon (as apron) and
airport boundary are there and play nicely together. (runway line
added by hand)
http://www.openstreetmap.org/?lat=-43.81312&lon=-176.46314&zoom=15
>> I don't know for sure, but I somehow doubt Pitt Island has more than a
>> grass strip. :) I think you can be pretty comfortable that LINZ
>> provides runway polygons and OSM wants a line in this case.
>
> not necessarily - LINZ could well include the entire airfield as an area
as above. "Definition: The usable surface where aircraft land and take-off."
but as seen in the main chatham airport, some taxiway is there too.
>> fwiw, from your AKL url,
>> http://www.openstreetmap.org/?lat=-37.01079&lon=174.78576&zoom=16
>> -Export tab-
>> [*] OpenStreetMap XML Data
>> Save As... AKL_airport.osm
>>
>> $ grep 'tag' AKL_airport.osm | sort | uniq
>
> yep. has that helped with how airports are tagged in osm? can you
> adjust the LINZ import rules to tag things appropriately?
do our best to be logical and match what the existing conventions are
I guess, but don't throw out any data needlessly.
If Joe's script in osm svn isn't the one being used I don't know what to edit.
regards,
Hamish
Glen Barnes
The airports layer get imported as aeroway=aerodrome. In the Chathams
example this would import the main airport.
The runways layer gets imported as aeroway=apron. This is more like
what the actual data shows. The base layer is a polygon and the
examples at the LINZ page do show the whole area as opposed to just
the runway.
Runways will have to be manually entered by hand after the imports are
done.
I'll update the mapping file to take this into account and we can try
a different part of the country to make sure that works OK.
Also a note on the runway on PItt Island. The reason that this was
different from the others is that I had already tried to do some hand
editing on it.
Glen
PS: Be patient on the full write up of the tool we are using. Details
coming soon - I've been at the beach all Easter and haven't had a
chance to get things written up.
On Apr 2, 5:36 pm, Hamish <hamish.bow...@gmail.com> wrote:
> Robin wrote:
> > well, an airport and a runway are two different things of course.
>
> > if the data you are importing is an airport, it should be tagged as an
> > airport, if it's a runway, it should be tagged as a runway. without
> > seeing that data in the context of everything else round there/other
> > airports in the data set, it's hard to say what they were trying to
> > indicate in the LINZ data
>
> > could you look at the LINZ data for auckland airport? that might give
> > us some more context
>
> looking at the LINZ layers at Koordniates.com there are a few:
> http://koordinates.com/layers/category/air-aviation/
>
> * runways/airstrips (vector polygons)
> * airports (vector polygons)
> * helipads (points)
>
> the descriptions at the above weblink are pretty clear about what they show.
>
> see the main chatham airport.. both runway polygon (as apron) and
> airport boundary are there and play nicely together. (runway line
> added by hand)http://www.openstreetmap.org/?lat=-43.81312&lon=-176.46314&zoom=15
Robin Paulson
> The airports layer get imported as aeroway=aerodrome. In the Chathams
> example this would import the main airport.
>
> The runways layer gets imported as aeroway=apron. This is more like
> what the actual data shows. The base layer is a polygon and the
> examples at the LINZ page do show the whole area as opposed to just
> the runway.
i've taken a look at the airport on chatham island, and it seems an
overly complicated way of tagging an airport
there's no need to use the multipolygon relation - that's for a very
specific set of objects which are related in a certain way, and it
doesn't have any relevance here. there's no need for any relations
here. all the tags applied to the relations can be applied directly to
the outer (aerodrome) and inner (apron) ways
> --
> You received this message because you are subscribed to the Google Groups "nzopengis" group.
> To post to this group, send email to nzop...@googlegroups.com.
> To unsubscribe from this group, send email to nzopengis+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nzopengis?hl=en.
>
>
Glen Barnes
On Apr 6, 10:31 am, Robin Paulson <robin.paul...@gmail.com> wrote:
> On 5 April 2010 16:50, Glen Barnes <barnaclebar...@gmail.com> wrote:
>
> i've taken a look at the airport on chatham island, and it seems an
> overly complicated way of tagging an airport
>
> there's no need to use the multipolygon relation - that's for a very
> specific set of objects which are related in a certain way, and it
> doesn't have any relevance here. there's no need for any relations
> here. all the tags applied to the relations can be applied directly to
> the outer (aerodrome) and inner (apron) ways
>
Yep - We will update the way Polygons are exported from the conversion
script to take this into account. It still stands though that runways
will be tagged as aprons, airports get tagged as aerodromes and
runways need to be manually added.
Hamish
Hamish
Robin Paulson
> Hey Robin,
> Any comment on my reply? Otherwise I'll go ahead and make a change for
> single-ring polygons.
> Rob :)
>
>> I'm producing multipolygons from the tool because it's a generic solution
>> for the geometry type. From that page:
yeah, but it's not as simple as that. it means generic for a certain
set of conditions, which our import doesn't match. multipolygons are
used for example where there is a forest with a non-forest bit, wholly
surrounded by trees. it enables the creation of a hole, which doesn't
exist here
>> As a shortcut for mappers, areas can also be modeled by creating one
>> circular way and tag it with something that suggests an area rather than a
>> circular way (for example, a circular way tagged landuse=forest will be
>> assumed to be an area, while a circular way tagged junction=roundabout will
>> not). However, this kind of shortcut only works for simple areas the outline
>> of which consists of one single way, and which do not have holes.
some things are assumed to be areas (e.g. leisure=park), some are not
(e.g. highway=pedestrian), but can be tagged as such (with area=yes)
in the case of say a public square (e.g. aotea square in auckland). in
the case of an airport, it's assumed by the renderer to be an area, so
no need to do anytihng else.
>> "shortcut" means to me "don't do it unless you're feeling lazy"... maybe
>> i'm misinterpreting?
>> I can make it so that if the geometry is a single polygon with no inner
>> rings it'll end up as a way... but is that a good solution going forward?
no - a circular way becomes a polygon by the simple act of joining the
two ends together
you can ditch the relations altogether here, there's nothing
complicated enough to need them
Hamish
> yeah, but it's not as simple as that. it means generic for a certain
> set of conditions, which our import doesn't match. multipolygons are
> used for example where there is a forest with a non-forest bit, wholly
> surrounded by trees. it enables the creation of a hole, which doesn't
> exist here
it makes sense for the runway_poly when aerodrome=apron when there is
enclosed grass between the runway and the taxiway. Doesn't matter for
airstrips and Dunedin Airport, but does for most other main centres.
Hamish
Hamish
notice some have that, some do not.
Robin Paulson
> it makes sense for the runway_poly when aerodrome=apron when there is
> enclosed grass between the runway and the taxiway. Doesn't matter for
> airstrips and Dunedin Airport, but does for most other main centres.
yeah, i guess. you could argue the grass is part of the apron too though?
Hamish
> yeah, i guess. you could argue the grass is part of the apron too though?
http://wiki.openstreetmap.org/wiki/Airports
"Often there are large areas of grass within the airport site. These
should be drawn as areas and tagged with landuse=grass."
Hamish
Robin Paulson
true, but take a look at the mapping of the airport suggested - there
are no multipolygon relations, the grass is dropped on top of the
apron, which i'm happy with
i think you may be making it a lot more complicated than you expect by
tagging it with multipolygons, but give it a go. we can always revert
and try again
Hamish
10 of them..) will be done by hand already anyway. In the same way
that I'm not at all worried about spaghetti junction because it only
happens once or twice. IMO for the bulk import we should heed your
warning and focus on what's best for the 500 little airstrips. Best
would be to use PostGIS to set the Relation when needed, but otherwise
just a simple area.
Hamish
Robert Coup
in Rob's javascript app, should value="foo" get a trailing ; or not? I
notice some have that, some do not.
Robert Coup
no - a circular way becomes a polygon by the simple act of joining thetwo ends together
you can ditch the relations altogether here, there's nothing
complicated enough to need them
Glen Barnes
javascript in a box otherwise it doesn't need it (from what I
cantell_. I've sometimes put it in and sometimes not.
Hamish
> ok, so let me get this straight:
> - for multipolygons, or polygons with inner rings (holes), do the relation
> thing.
> - for polygons with a single ring (most of them), create a circular way,
> with firstnode=lastnode
> - don't tag them all "area=yes", people should do it manually as
> appropriate
right, right, and right. area is usually decided automatically by the
nature of the tag (the various Key: pages in the osm wiki show an icon
for the point/line/polygon/relation they are valid for).
and nodes are both points in space and vertices of polylines (ways) or
polygons (closed ways). So the last vertex of the boat ramp can be
both the end of the road and hold the tag which gives it the boat ramp
symbol, and railway stations can be tags on the nearest vertext of the
polyline (way) describing the railroad tracks.
ultra-simple features.
One nagging question I have about the data model: if you have say a
park surrounded by roads, should you snap the grass area to the road,
or try to make it end at the sidewalk? How about if you have two
adjoining areas like a schoolyard next to an airport grounds? can the
two areas share a boundary/nodes or should you make two parallel
boundaries which almost touch, but not quite?
Hamish
ps- I was going to grab the v14 NZ coastline polygon from koord's and
quickly make two inside/outside sets of islands so we can separate
natural=coastline from natural=land, but I see in the 2007 coastline
poly comments section that Kim O. has already done it for the offshore
islands and uploaded it as Seacoast. I might do it anyway to get the
inland islands in their own layer. Please stop me if I'm making
unnecessary work for myself. I've already got an old NZ polygon with
offshore islands, but it's probably time to upgrade.
Robin Paulson
> right, right, and right. area is usually decided automatically by the
> nature of the tag (the various Key: pages in the osm wiki show an icon
> for the point/line/polygon/relation they are valid for).
>
> and nodes are both points in space and vertices of polylines (ways) or
> polygons (closed ways). So the last vertex of the boat ramp can be
> both the end of the road and hold the tag which gives it the boat ramp
> symbol, and railway stations can be tags on the nearest vertext of the
> polyline (way) describing the railroad tracks.
>
> ultra-simple features.
>
> One nagging question I have about the data model: if you have say a
> park surrounded by roads, should you snap the grass area to the road,
no!
> or try to make it end at the sidewalk? How about if you have two
yes. the park ends at the edge of the park, not an arbitrary point in
space somewhere beyond that. there's not been a decision yet on how to
tag road corridors
> adjoining areas like a schoolyard next to an airport grounds? can the
> two areas share a boundary/nodes or should you make two parallel
> boundaries which almost touch, but not quite?
ideally, they should share nodes. if there's no gap on the ground
between the two, there's no gap in the data either