A project for winter - Building heights

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

A project for winter - Building heights

OJ W
Now that the building-outlines have been done in London and elsewhere,
and with flight-simulator projects asking about 3D data, it might be
worth tagging the heights of some skyscrapers.

Every significant building has a wikipedia article, nearly all of
which include details of the height

http://en.wikipedia.org/wiki/8_Canada_Square

http://en.wikipedia.org/wiki/Category:Skyscrapers_by_city


what other tags can you think of for describing buildings?  Some
peoples' ideas are at:

http://wiki.openstreetmap.org/index.php/Proposed_features/Building_attributes


To see progress in a city, Kosmos seems to be capable of drawing
things differently according to their height, e.g. there's an example
rule in:

http://wiki.openstreetmap.org/index.php/Kosmos_AirNav_Rules#Tall_buildings



p.s. will anyone make an isometric slippy-map next?

_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: A project for winter - Building heights

Jon Burgess
On Sun, 2008-11-02 at 19:08 +0000, OJ W wrote:

> Now that the building-outlines have been done in London and elsewhere,
> and with flight-simulator projects asking about 3D data, it might be
> worth tagging the heights of some skyscrapers.
>
> Every significant building has a wikipedia article, nearly all of
> which include details of the height
>
> http://en.wikipedia.org/wiki/8_Canada_Square
>
> http://en.wikipedia.org/wiki/Category:Skyscrapers_by_city
>
>
> what other tags can you think of for describing buildings?  Some
> peoples' ideas are at:
>
> http://wiki.openstreetmap.org/index.php/Proposed_features/Building_attributes
>
>
> To see progress in a city, Kosmos seems to be capable of drawing
> things differently according to their height, e.g. there's an example
> rule in:
>
> http://wiki.openstreetmap.org/index.php/Kosmos_AirNav_Rules#Tall_buildings
>
>
>
> p.s. will anyone make an isometric slippy-map next?

Like this? http://artem.dev.openstreetmap.org/files/osm_3d.png

http://lists.openstreetmap.org/pipermail/talk/2007-September/018019.html

        Jon




_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: A project for winter - Building heights

Frederik Ramm
In reply to this post by OJ W
Hi,

Jon Burgess wrote:
> Like this? http://artem.dev.openstreetmap.org/files/osm_3d.png

or

http://igorbrejc.net/openstreetmap/openstreetmap-3d-short-video

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"

_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Proposed Relations

David Groom
In reply to this post by OJ W
The page
http://wiki.openstreetmap.org/index.php/Relations#Proposed_uses_of_Relations 
has a large number of proposed uses of relations, but there never seems to
be any forward movement on these.

However flawed the voting system for proposed tags is, at least there is a
recognised procedure, and eventually proposed tags either make it into the
mainstream of OSM or they don't.  But this doesn't seem to be the case with
proposed relations.

I suspect the reason for this might be twofold.

Firstly there is no recognised procedure for moving these forward.

Secondly, and perhaps more importantly, many of the proposed uses of
relations require some degree of knowledge of what the main renderers /
other users of OSM data can actually cope with.  So for instance there would
be no point in me trying to move a particular proposal forward as I don't
know if in practice the aim of the proposal can be achieved.

I'm afraid I don't have a solution to the problem, but just wanted to flag
it up as an issue.

David




_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Relations

Andy Allan
On Mon, Nov 3, 2008 at 12:31 PM, David Groom <[hidden email]> wrote:
> The page
> http://wiki.openstreetmap.org/index.php/Relations#Proposed_uses_of_Relations
> has a large number of proposed uses of relations, but there never seems to
> be any forward movement on these.
>
> However flawed the voting system for proposed tags is, at least there is a
> recognised procedure, and eventually proposed tags either make it into the
> mainstream of OSM or they don't.

It's a matter of debate as to causation/correlation between the voting
procedures and mainstream OSM :-)

> But this doesn't seem to be the case with
> proposed relations.
>
> I suspect the reason for this might be twofold.
>
> Firstly there is no recognised procedure for moving these forward.
>
> Secondly, and perhaps more importantly, many of the proposed uses of
> relations require some degree of knowledge of what the main renderers /
> other users of OSM data can actually cope with.  So for instance there would
> be no point in me trying to move a particular proposal forward as I don't
> know if in practice the aim of the proposal can be achieved.
>
> I'm afraid I don't have a solution to the problem, but just wanted to flag
> it up as an issue.

I would suggest concentrating on documenting the ones that are in use,
such as multipolygons, cycle route relations. Even better is to
concentrate on the ones that are in the db and widely consumed (by
e.g. a renderer), then on the ones in the db but not widely consumed
(e.g. turn restrictions) and pretty much ignore the fanciful
I-think-it-would-be-great-if suggestions.

Cheers,
Andy

_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Relations

David Groom
----- Original Message -----
From: "Andy Allan" <[hidden email]>
To: "David Groom" <[hidden email]>
Cc: "Talk Openstreetmap" <[hidden email]>
Sent: Monday, November 03, 2008 12:40 PM
Subject: Re: [OSM-talk] Proposed Relations


>
> On Mon, Nov 3, 2008 at 12:31 PM, David Groom <[hidden email]>
> wrote:
>> The page
>> http://wiki.openstreetmap.org/index.php/Relations#Proposed_uses_of_Relations
>> has a large number of proposed uses of relations, but there never seems
>> to
>> be any forward movement on these.
>>
>> However flawed the voting system for proposed tags is, at least there is
>> a
>> recognised procedure, and eventually proposed tags either make it into
>> the
>> mainstream of OSM or they don't.
>
> It's a matter of debate as to causation/correlation between the voting
> procedures and mainstream OSM :-)
>
>> But this doesn't seem to be the case with
>> proposed relations.
>>
>> I suspect the reason for this might be twofold.
>>
>> Firstly there is no recognised procedure for moving these forward.
>>
>> Secondly, and perhaps more importantly, many of the proposed uses of
>> relations require some degree of knowledge of what the main renderers /
>> other users of OSM data can actually cope with.  So for instance there
>> would
>> be no point in me trying to move a particular proposal forward as I don't
>> know if in practice the aim of the proposal can be achieved.
>>
>> I'm afraid I don't have a solution to the problem, but just wanted to
>> flag
>> it up as an issue.
>
> I would suggest concentrating on documenting the ones that are in use,
> such as multipolygons, cycle route relations. Even better is to
> concentrate on the ones that are in the db and widely consumed
>by  e.g. a renderer),

Is there any easy way to find what relations fit into the above category?

> e.g. a renderer), then on the ones in the db but not widely consumed
> (e.g. turn restrictions)

I there any easy way to find what relations fit into the above category?

>and pretty much ignore the fanciful
> I-think-it-would-be-great-if suggestions.
>

Well I'm never a fan of "fanciful  I-think-it-would-be-great-if
suggestions."  :)

But I do see, for instance, great advantages to the
http://wiki.openstreetmap.org/index.php/Relations/Proposed/Collected_Ways 
and
http://wiki.openstreetmap.org/index.php/Relations/Proposed/Dual_carriageways 
proposals.

David


> Cheers,
> Andy
>



_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: A project for winter - Building heights

Stefan Baebler
In reply to this post by Frederik Ramm
a fun way for checking the dataset would surely be to have OSM maps in
3d simulations or games, such as
http://torcs.sourceforge.net/ or
http://sourceforge.net/projects/trigger-rally/ (picked at random,
other targets are welcome)

Imagine roadsigns showing restrictions, place & street names,
buildings as blocks, srtm for general terrain relief, show landuse and
some natural features....

A benefit would be to be able to make use JOSM remote control plugin
(or open up potlatch) to fix up spotted errors while game is paused :)

How about piste maps in Tux racer ? :D

Stefan


On Sun, Nov 2, 2008 at 10:23 PM, Frederik Ramm <[hidden email]> wrote:

> Hi,
>
> Jon Burgess wrote:
>> Like this? http://artem.dev.openstreetmap.org/files/osm_3d.png
>
> or
>
> http://igorbrejc.net/openstreetmap/openstreetmap-3d-short-video
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"
>
> _______________________________________________
> talk mailing list
> [hidden email]
> http://lists.openstreetmap.org/listinfo/talk
>
_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Relations

Pieren
In reply to this post by David Groom
On Mon, Nov 3, 2008 at 2:15 PM, David Groom

I'm also surprised that the relation type=boundary is still considered
as a proposal in the wiki.
Having a quick look on the european statistics about relations in
tagwatch ([1]), the most popular relation "is" type=boundary (10297),
most of them for admin_level=8 (municipalities).
This is an example of "approved" relation which does not require a
vote because it's already widely used.

On the other side, the fifth most popular relation in tagwatch is the
type="-" (1107) where most of the linked objects have the role=<empty>
!

Pieren

[1] http://tagwatch.stoecker.eu/Europe/En/relationslist.html

_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: A project for winter - Building heights

Iván Sánchez Ortega
In reply to this post by Stefan Baebler
El Lunes, 3 de Noviembre de 2008, Stefan Baebler escribió:
> a fun way for checking the dataset would surely be to have OSM maps in
> 3d simulations or games, such as
> http://torcs.sourceforge.net/ or
> http://sourceforge.net/projects/trigger-rally/ (picked at random,
> other targets are welcome)

Naahhh... I'm thinking in Grand Theft Auto: OSM. If just because the road
network would allow the automata (cars and peds) to move around.

> How about piste maps in Tux racer ? :D

Whoa, that's a *cool* idea! (pun intended). This should be added to the list
of student projects.

--
----------------------------------
Iván Sánchez Ortega <[hidden email]>

Un ordenador no es un televisor ni un microondas, es una herramienta compleja.

_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Relations

Andy Allan
In reply to this post by David Groom
On Mon, Nov 3, 2008 at 1:15 PM, David Groom <[hidden email]> wrote:

>> I would suggest concentrating on documenting the ones that are in use,
>> such as multipolygons, cycle route relations. Even better is to
>> concentrate on the ones that are in the db and widely consumed
>> by  e.g. a renderer),
>
> Is there any easy way to find what relations fit into the above category?
>
>> e.g. a renderer), then on the ones in the db but not widely consumed
>> (e.g. turn restrictions)
>
> I there any easy way to find what relations fit into the above category?

It's reasonably easy to find out what ones are in use in the db, but
harder to find out which are consumed. Yet still fairly
straightforward detective work for someone with a good knowledge of
OSM.

Frederik, next time we have a discussion group like the one on
relations at SOTM, remind me to video and/or transcribe it :-)

Cheers,
Andy

_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Relations

Hakan Tandogan
In reply to this post by Pieren

On Mon, November 3, 2008 14:49, Pieren wrote:
> On Mon, Nov 3, 2008 at 2:15 PM, David Groom
>
>
> I'm also surprised that the relation type=boundary is still considered
> as a proposal in the wiki. Having a quick look on the european statistics
> about relations in tagwatch ([1]), the most popular relation "is"
> type=boundary (10297), most of them for admin_level=8 (municipalities).
> This is an example of "approved" relation which does not require a
> vote because it's already widely used.

By the way, are relations guaranteed to be ordered? If not, how could one
be sure to stitch all parts of a long border? Do we need a rule like "the
border has to be a unbroken set of ways" like for the coast lines?


Regards,
Hakan

--
The key to immortality is first living a life worth remembering...



_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Relations

Shaun McDonald

On 3 Nov 2008, at 15:08, Hakan Tandogan wrote:

>
> On Mon, November 3, 2008 14:49, Pieren wrote:
>> On Mon, Nov 3, 2008 at 2:15 PM, David Groom
>>
>>
>> I'm also surprised that the relation type=boundary is still  
>> considered
>> as a proposal in the wiki. Having a quick look on the european  
>> statistics
>> about relations in tagwatch ([1]), the most popular relation "is"
>> type=boundary (10297), most of them for admin_level=8  
>> (municipalities).
>> This is an example of "approved" relation which does not require a
>> vote because it's already widely used.
>
> By the way, are relations guaranteed to be ordered? If not, how  
> could one
> be sure to stitch all parts of a long border? Do we need a rule like  
> "the
> border has to be a unbroken set of ways" like for the coast lines?
>
Relations are unordered. You could load the relation and all the ways  
referenced by it, then check to see if each way has another way that  
has the same start and end nodes, through a process of stitching.

Shaun


_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Relations

Frederik Ramm
Hi,

Shaun McDonald wrote:
> Relations are unordered. You could load the relation and all the ways
> referenced by it, then check to see if each way has another way that has
> the same start and end nodes, through a process of stitching.

1. Shaun is right BUT

2. I want relations to become ordered and will try to sneak this into
API 0.6; there will be no noticeable change for any API client, just
that it so happens that things are returned in the order you put them
in, rather than in any order. The rationale behind that is that people
start (ab)using the role attribute for that (e.g. a bus route with nodes
that have the roles "stop1", "stop2", "stop3" etc.), which of course is
a pain to modify.

3. No matter wheter API 0.6 will have ordered relations or not, I
suggest to never rely on ordering in cases where it can be derived from
the contents, i.e. if you have a border relation then by all means look
at the first/last nodes of the ways and connect them rather than just
assuming the elements are in the correct order.

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"

_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Relations

Frederik Ramm
In reply to this post by Pieren
Hi,

Pieren wrote:
> I'm also surprised that the relation type=boundary is still considered
> as a proposal in the wiki.

[...]

> This is an example of "approved" relation which does not require a
> vote because it's already widely used.

There are no "approved" relations; there are those that are proposed and
those that are established. A relation becomes established once it er,
establishes itself ;-)

The formal process to move a relation from "proposed" to "established"
is to use your favourite editor and create lots of instances of the
relation where it makes sense, ideally in a way that annoys as few
others as possible.

I believe the "boundary" relation should be clearly flagged as
"established". I wanted to move it up on the "Relations" page but I find
that the "Proposed" section is much better structured, plus we have a
naming convention problem ("Relation:restriction" vs.
"Relations/Proposed/Boundaries"). Should we rename
Relations/Proposed/Boundaries to Relation:bondary?

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"

_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Relations

Karl Newman
In reply to this post by Frederik Ramm
On Mon, Nov 3, 2008 at 4:34 PM, Frederik Ramm <[hidden email]> wrote:
Hi,

Shaun McDonald wrote:
> Relations are unordered. You could load the relation and all the ways
> referenced by it, then check to see if each way has another way that has
> the same start and end nodes, through a process of stitching.

1. Shaun is right BUT

2. I want relations to become ordered and will try to sneak this into
API 0.6; there will be no noticeable change for any API client, just
that it so happens that things are returned in the order you put them
in, rather than in any order. The rationale behind that is that people
start (ab)using the role attribute for that (e.g. a bus route with nodes
that have the roles "stop1", "stop2", "stop3" etc.), which of course is
a pain to modify.
 
If you're sneaking relation changes into the API, could you also allow a member to be repeated? This would be useful in describing a prohibited U-turn on a single carriageway. The same way would need to be in both the "from" and "to" roles, which I believe is currently prohibited.

Karl

_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Relations

Lennard
In reply to this post by Frederik Ramm
Frederik Ramm wrote:

> 2. I want relations to become ordered and will try to sneak this into
> API 0.6; there will be no noticeable change for any API client, just
> that it so happens that things are returned in the order you put them
> in, rather than in any order.

There is one noticeable change here to clients: if they download such an
ordered relation, and upload a newer version, they should have kept the
ordering intact.

The current unordered relations mean that a client can store it locally
however it likes, and upload it in a completely different order, and it
won't make one iota of difference to anyone. That assumption would
become invalid.

--
Lennard

_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Relations

Frederik Ramm
Hi,

>> 2. I want relations to become ordered and will try to sneak this into
>> API 0.6; there will be no noticeable change for any API client, just
>> that it so happens that things are returned in the order you put them
>> in, rather than in any order.
>
> There is one noticeable change here to clients: if they download such an
> ordered relation, and upload a newer version, they should have kept the
> ordering intact.
>
> The current unordered relations mean that a client can store it locally
> however it likes, and upload it in a completely different order, and it
> won't make one iota of difference to anyone. That assumption would
> become invalid.

True but this only applies as soon as ordering is actually used.
Currently everyone has to assume that they get the data back shuffled,
and whether that shuffling was done by the API (as it is now) or by an
order-unaware client doesn't make a difference. Of course, as soon as we
use that new feature, clients will be expected to respect ordering.

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"

_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Relations

Lennard
Frederik Ramm wrote:

> True but this only applies as soon as ordering is actually used.

That's why I said it would _become_ invalid. It is not an issue right now.

> Currently everyone has to assume that they get the data back shuffled,
> and whether that shuffling was done by the API (as it is now) or by an
> order-unaware client doesn't make a difference. Of course, as soon as we
> use that new feature, clients will be expected to respect ordering.

How would you detect order-unaware clients uploading such an ordered
relation? There is no capability exchange between client and server, so
you can't know if the client is order-aware. Or would you propose that
any client using API 0.6 is order-aware at the moment of the official
migration to 0.6? Next to the mainstream editors, you'd also still have
the issue of broken clients, scripts, bots.

--
Lennard

_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Relations

Frederik Ramm
Hi,

Ldp wrote:
> How would you detect order-unaware clients uploading such an ordered
> relation?

I wouldn't bother. My timeline:

1. Build the feature into API 0.6 and tell nobody about it. Nobody will
notice, nobody has to change what he does.
2. Make sure the big three editors support ordering. Nobody will notice,
nobody has to change what he does. Also, try and get Osmosis and the
various mirror services (ROMA, XAPI) to support ordered relations.
3. Once this is working to a sufficient degree, announce that ordered
relations are now possible (if required, issue some caveats like "but
doesn't work in XYZ yet"), and would anyone using their own client or a
niche editor please make sure to respect this.
4. If someone messes things up, the human beings involved can sort that
out. It is not the API's responsibility to make sure that clients work
correctly.

I'm not in the mood for a complex capability exchange between server and
client although if we should make the creation of a changeset mandatory
in 0.6 then the "create changeset" request would be an ideal place to
add such things.

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"

_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Relations

Karl Newman
On Wed, Nov 5, 2008 at 3:38 PM, Frederik Ramm <[hidden email]> wrote:
2. Make sure the big three editors support ordering. Nobody will notice,
nobody has to change what he does. Also, try and get Osmosis and the
various mirror services (ROMA, XAPI) to support ordered relations.

I can confirm that Osmosis already maintains the order of relations.

Karl

_______________________________________________
talk mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/talk
12