Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ele with alpine_hut when mapped as a building #101

Closed
al-- opened this issue Aug 6, 2013 · 7 comments · Fixed by #2533
Closed

ele with alpine_hut when mapped as a building #101

al-- opened this issue Aug 6, 2013 · 7 comments · Fixed by #2533
Assignees
@kocio-pl
Labels
addressing bug new features Requests to render new features
Milestone
Database layout c...

Comments

@al--
Copy link

al-- commented Aug 6, 2013

Wish: If a building is tagged as tourism=alpine_hut, it would be fine if the ele was shown (as is done if it is mapped as a node).

91464 1
http://www.openstreetmap.org/browse/way/232521425
91450 1
http://www.openstreetmap.org/browse/node/389786530
@brycenesbitt
Copy link

+1 on this

@pnorman
Copy link
Collaborator

pnorman commented Sep 30, 2013

This turns out to be an issue with the osm2pgsql style - we don't have ele information in-DB for ways.

@mrwojo mrwojo mentioned this issue Mar 11, 2014
Closed
@pnorman pnorman added this to the 3.x - Needs upgrade to mapnik or openstreetmap-carto.style milestone Aug 28, 2014
@sommerluk sommerluk mentioned this issue Apr 6, 2015
Merged
@matthijsmelissen matthijsmelissen mentioned this issue Apr 28, 2015
Closed
6 tasks
matthijsmelissen added a commit to matthijsmelissen/openstreetmap-carto that referenced this issue Apr 3, 2016
@matthijsmelissen
Change documentation for osm2pgsql import
26d90f7 
This adds -G, --hstore and the lua tag transform to the documentation
for the osm2pgsql import.

This resolves gravitystorm#101.
@matthijsmelissen matthijsmelissen mentioned this issue Apr 3, 2016
Closed
matthijsmelissen added a commit to matthijsmelissen/openstreetmap-carto that referenced this issue May 16, 2016
@matthijsmelissen
**This is a pull-request against the lua branch**
6427fc8 
This PR proposes a database-reload. It changes the documentation on the use of
osm2pgsql, and adds a .lua file for preprocessing.

This database import aims to be backwards compatible with older versions of
the style.

This resolves (at least part of) gravitystorm#1504.

Adding the hstore option to osm2pgsql allows the database to use all keys.

This PR proposes using hstore for new keys, and using traditional columns for
old keys. This allows us to stay compatible with old versions of the style.

According to [@pnorman's benchmarks](http://www.paulnorman.ca/blog/2014/03/osm2pgsql-and-hstore/),
using hstore without dropping columns would lead to a 9% size increase and a
0.38% speed decrease. Given the benefits of having all columns available, I
would consider this acceptable.

This is based on the following unmerged PR to osm2pgsql:
osm2pgsql-dev/osm2pgsql#346

It makes the polygon/linestring decision based on the tag value, in addition to
the tag key. In particular, highway=services and junction=yes are now treated as
polygon, while leisure=track, man_made=embankment, man_made=breakwater,
man_made=groyne, natural=cliff, natural=tree_row, historic=citywalls,
waterway=derelict_canal, waterway=ditch, waterway=drain, waterway=river,
waterway=stream, waterway=wadi, waterway=weir, power=line, and power=minor_line
are now treated as linestring.

This resolves gravitystorm#1362, resolves gravitystorm#137, resolves gravitystorm#268, and resolves gravitystorm#892.

The new .lua file creates a osmcarto_z_order value in the database, which stores
the rendering order we use. This will allow us to simplify the road queries.

This resolves gravitystorm#59.

This resolves gravitystorm#101.

The .lua file drops some more meta-information from imports that is of no
need for rendering.

This is based on the following unmerged PR to osm2pgsql:
* osm2pgsql-dev/osm2pgsql#532
@matthijsmelissen matthijsmelissen mentioned this issue May 16, 2016
Closed
matthijsmelissen added a commit to matthijsmelissen/openstreetmap-carto that referenced this issue May 16, 2016
@matthijsmelissen
**This is a pull-request against the lua branch**
d767022 
This PR proposes a database-reload. It changes the documentation on the use of
osm2pgsql, and adds a .lua file for preprocessing.

This database import aims to be backwards compatible with older versions of
the style.

This resolves (at least part of) gravitystorm#1504.

 #Hstore
Adding the hstore option to osm2pgsql allows the database to use all keys.

This PR proposes using hstore for new keys, and using traditional columns for
old keys. This allows us to stay compatible with old versions of the style.

According to [@pnorman's benchmarks](http://www.paulnorman.ca/blog/2014/03/osm2pgsql-and-hstore/),
using hstore without dropping columns would lead to a 9% size increase and a
0.38% speed decrease. Given the benefits of having all columns available, I
would consider this acceptable.

 # Make polygon/linestring decision based on value
This is based on the following unmerged PR to osm2pgsql:
osm2pgsql-dev/osm2pgsql#346

It makes the polygon/linestring decision based on the tag value, in addition to
the tag key. In particular, highway=services and junction=yes are now treated as
polygon, while leisure=track, man_made=embankment, man_made=breakwater,
man_made=groyne, natural=cliff, natural=tree_row, historic=citywalls,
waterway=derelict_canal, waterway=ditch, waterway=drain, waterway=river,
waterway=stream, waterway=wadi, waterway=weir, power=line, and power=minor_line
are now treated as linestring.

This resolves gravitystorm#1362, resolves gravitystorm#137, resolves gravitystorm#268, and resolves gravitystorm#892.

 # Rendering order
The new .lua file creates a osmcarto_z_order value in the database, which stores
the rendering order we use. This will allow us to simplify the road queries.

 # Recommend -G flag for multipolygons
This resolves gravitystorm#59.

 # Import ele on buildings
This resolves gravitystorm#101.

 # Delete more meta-tags from imports
The .lua file drops some more meta-information from imports that is of no
need for rendering.

This is based on the following unmerged PR to osm2pgsql:
* osm2pgsql-dev/osm2pgsql#532
@matthijsmelissen matthijsmelissen mentioned this issue May 16, 2016
Merged
matthijsmelissen added a commit to matthijsmelissen/openstreetmap-carto that referenced this issue May 16, 2016
@matthijsmelissen
Database reload
d48106e 
**This is a pull-request against the lua branch**

This PR proposes a database-reload. It changes the documentation on the use of
osm2pgsql, and adds a .lua file for preprocessing.

This database import aims to be backwards compatible with older versions of
the style.

This resolves (at least part of) gravitystorm#1504.

 #Hstore
Adding the hstore option to osm2pgsql allows the database to use all keys.

This PR proposes using hstore for new keys, and using traditional columns for
old keys. This allows us to stay compatible with old versions of the style.

According to [@pnorman's benchmarks](http://www.paulnorman.ca/blog/2014/03/osm2pgsql-and-hstore/),
using hstore without dropping columns would lead to a 9% size increase and a
0.38% speed decrease. Given the benefits of having all columns available, I
would consider this acceptable.

 # Make polygon/linestring decision based on value
This is based on the following unmerged PR to osm2pgsql:
osm2pgsql-dev/osm2pgsql#346

It makes the polygon/linestring decision based on the tag value, in addition to
the tag key. In particular, highway=services and junction=yes are now treated as
polygon, while leisure=track, man_made=embankment, man_made=breakwater,
man_made=groyne, natural=cliff, natural=tree_row, historic=citywalls,
waterway=derelict_canal, waterway=ditch, waterway=drain, waterway=river,
waterway=stream, waterway=wadi, waterway=weir, power=line, and power=minor_line
are now treated as linestring.

This resolves gravitystorm#1362, resolves gravitystorm#137, resolves gravitystorm#268, and resolves gravitystorm#892.

 # Rendering order
The new .lua file creates a osmcarto_z_order value in the database, which stores
the rendering order we use. This will allow us to simplify the road queries.

 # Recommend -G flag for multipolygons
This resolves gravitystorm#59.

 # Import ele on buildings
This resolves gravitystorm#101.

 # Delete more meta-tags from imports
The .lua file drops some more meta-information from imports that is of no
need for rendering.

This is based on the following unmerged PR to osm2pgsql:
* osm2pgsql-dev/osm2pgsql#532
@pnorman pnorman mentioned this issue Jan 3, 2017
Merged
5 tasks
@pnorman
Copy link
Collaborator

pnorman commented May 10, 2017

Reopening, I think there's still some changes that need to be done to enable this.

@pnorman pnorman reopened this May 10, 2017
@kocio-pl kocio-pl self-assigned this Sep 10, 2017
@matthijsmelissen
Copy link
Collaborator

After #2823 is merged, this will be the oldest open issue!

@kocio-pl
Copy link
Collaborator

@sommerluk I guess you could extend elevation rendering for polygons or help me with this?

I've tried to copy this block:

openstreetmap-carto/project.mml

Lines 2020 to 2024 in 8862ee4

CONCAT(
name,
CASE WHEN name IS NOT NULL AND elevation IS NOT NULL THEN E'\n' ELSE NULL END,
CASE WHEN elevation IS NOT NULL THEN CONCAT(REPLACE(ROUND(elevation)::TEXT, '-', U&'\2212'), U&'\00A0', 'm') ELSE NULL END
) AS name,

and this one (without "natural" part):

openstreetmap-carto/project.mml

Lines 2085 to 2092 in 8862ee4

CASE
WHEN "natural" IN ('peak', 'volcano', 'saddle') OR tourism = 'alpine_hut' OR amenity = 'shelter' THEN
CASE
WHEN tags->'ele' ~ '^-?\d{1,4}(\.\d+)?$' THEN (tags->'ele')::NUMERIC
ELSE NULL
END
ELSE NULL
END AS elevation,

to a text-poly layer, but then I get:

Postgis Plugin: ERROR:  column "elevation" does not exist

The text-point layer doesn't have this problem.

@sommerluk
Copy link
Collaborator

I’m not sure. Could you make the code available on Github?

Just raw guess: text-point is composed by a SELECT and a sub-SELECT. The code for the name-elevation-combination is part of the outer SELECT and needs the column elevation which does not come from the database (the database only provides ele), but it created in the inner SELECT. text-poly does not have nested SELECT. If you haven’t created one, you cannot query elevation at this level.

@kocio-pl
Copy link
Collaborator

You were right probably, I didn't spot the SELECT is nested. Could you try to fix this issue?

@sommerluk sommerluk mentioned this issue Oct 15, 2017
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@kocio-pl kocio-pl

Labels
addressing bug new features Requests to render new features
Projects
None yet
Milestone
Database layout change
6 participants
@pnorman @brycenesbitt @al-- @matthijsmelissen @kocio-pl @sommerluk