Re: [OSM-talk] Too many nodes?

[Jo]

Ari Torhamo schreef:
> Hello,
>
> I have a question regarding the amount of nodes that one may use to draw
> a road, and whether the amount of nodes used has a considerable effect
> on the speed of the OpenStreetMap.
>
> I did my first edits to OSM a few days ago. I'll get a GPS device soon,
> but so far my only edits have been adding street names and making roads
> more accurate by adding more nodes to curves, etc. Following these
> edits, another person who has edited the same area earlier, contacted me
> and told me not to add unnecessary nodes to roads that he has made long
> time ago and added that he has already removed the unnecessary nodes.
> According to him using many nodes slows down the rendering and routing.
>
> This made me wonder, what really is the right amount of nodes to use,
> when one want's the curves to be right and look really nice, but not to
> cause any problems by this. Can nodes be added as long as there are
> visible jaggies on the rendered map - even small ones - and just leave
> out the ones which have no affect on rendering (like nodes on a straight
> street)? It would be also good to know, if the speed of rendering and
> routing is a factor that should be concidered? I see now that in a few
> places I added some unnecessary nodes - for example I should have moved
> existing ones instead of adding new ones. Or perhaps I just looked at
> those curves too long - with full zoom - and those jaggies grew up in my
> mind to something bigger than they were :-) On the other hand, in many
> places I think that I made good changes and not many nodes should have
> been removed.
>
> I searched for information on this matter around the OSM web site and
> mailing lists, and found this page (see the section "Accuracy":
> http://wiki.openstreetmap.org/index.php/Editing_Standards_and_Conventions
> I would seem to me that my edits were relatively close to the example
> given there.
>
> I took some screenshots of the changes in question, so that people would
> get a better picture of what I'm talking about. I took screenshots of
> four different places that I edited, and three different versions of
> each of them. The version one shows the situation before my edits, the
> second one after my edits, and the third one after the removal of nodes
> by the original editor. The screenshots are here:
> http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/72157604611934407/
> (note that for some reason Flickr shows the pictures in a reverse
> alphabetical order). The zoomlevel used in the images is 16.
>
> It would be nice to get comments from people who know more about what's
> involved.
>   
I would just like to add to the other replies that before (re)moving 
nodes you should look at their properties. Sometimes they are at a 
specific place for a reason (bus stop, crossing, etc)

Polyglot

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Jo]

Robert (Jamie) Munro schreef:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Tom Hughes wrote:
> | In message <[EMAIL PROTECTED]>
> | Peter Miller <[EMAIL PROTECTED]> wrote:
>
> |> If we can agree on the rendering rules and get both Mapnik and osmarender
> |> sorted out for the USA then people will be incentivised to tag
> |> appropriately. The moto 'render and they will come' probably applies
> here as
> |> elsewhere.
> |
> | Agreeing on the rules or colour schemes is not the problem.
> |
> | The problem is that we do not have the technology to render different
> | countries in different ways. I don't believe we even know of an efficient
> | way to do it, so we don't even know what the technology would look like
> | should somebody want to write it.
>
> I don't think this is a problem we shuold be trying to solve. We should
> be solving the problem of the tile server only producing 1 rendering.
>
> When I look at the USA, I want interstates to be blue. When an American
> looks at the UK, they want to see motorways to be a colour other than
> blue, because then they will understand instinctively what kind of road
> it is. This should be one of the major benefits of OSM over other maps.
>
> When someone from a USA IP address opens the map, they should see the
> USA style tiles by default, but have the UK tiles on the layer switcher.
>   
That would indeed make a lot of sense. Otherwise you will get odd 
results of roads changing style near the borders. So a separate tile 
server for the US is called for. Probably one for France as well with 
styles that look like Michelin's maps and maybe one for Germany (Are 
Germans used to Kummerley und Frey?)

Polyglot

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] house numbers revisited

[Karl Newman]

On Fri, Apr 18, 2008 at 3:14 AM, Frederik Ramm <[EMAIL PROTECTED]> wrote:

> Hi,
>
> >>> * what if way direction is reversed?
> >>> * what if way is extended, merged, split?
> >>
> >>  That will be a problem indeed. Could theoretically be solved with
> >>  strong editor support, but that does not fix the intrinsic flaw. You
> >>  never know when a script comes around that reverses direction for
> >> some
> >>  valid reason, outside the editors. Someone on talk-nl suggested
> >> using
> >>  a NSEW-based tagging scheme, but this is not unambiguous either.
> >
> > I say these problems are irrelevent right now. We have other tags
> > (like oneway) which break when roads are reversed and that doesn't
> > seem to excite anyone enough to fix it. I'd say ignore that problem,
> > when it gets solved for other tags, it'll get solved for these also.
>
> The oneway tag dos not suffer from splitting a way. Oneway is
> displayed on the maps and sometimes in the editors as well so people
> will notice when they make mistakes. We'd have to work on giving
> house numbering the same prominence on map as oneway arrows if we
> want to enable people to spot bugs the same way they do with oneways.
>
> In another post you say that other GIS systems have no trouble using
> a left/right start/end scheme. One has to be careful when making
> these comparisons because many many GIS systems out there are
> basically read-only, or at least not at all intended for an
> environment like ours where changes are made on a massive scale by a
> massive amount of non-expert users. Something that works well for
> them does not necessarily work well for us. It might, but it doesn't
> follow logically.
>
> Bye
> Frederik
>

Keep in mind that this data will be used by more data consumers than just
putting numbers on the map. Geocoding apps and GPS maps need this in a
format that's easily parsed. The GIS world uses start-end left-right, and
this is what a lot of data consumers need, too (I'm thinking of Garmin GPS
maps) but I don't think that's the right way to store it in the database.

My suggestion on the relevant wiki page is to use relation to associate a
house number (really a street address number) to one node on one or two ways
(if the node falls at the junction of two ways which is a continuation of
the same street). Because certain output formats require it, we do need to
know if the number applies to the left or right and if the scheme is odd,
even, both and maybe "none" or "single" (for non-numeric addresses or
numbers which are not sequential?). With proper editor support, this is not
a big deal, and besides, the map is a Wiki--there will be mistakes, but they
can be corrected.

There are several advantages to this scheme. The first is that it doesn't
break anything if a way is split. Another advantage is that you can easily
add numbers at nodes to provide increased resolution if the spacing is
irregular and the interpolation gives unsatisfactory results. Regarding gaps
in numbers: They shouldn't be shown on the maps, but maybe you could add
special tag to a node indicating the start or end of a series.

The goal for this scheme is to locate a street address number at a relative
distance along a way. We're not trying to drop a bomb on a particular house
number using this data (I hope!). Do we really need to be concerned about
weird cases where you access an address via a different street?

Anyway, I think this is a simple scheme which addresses a lot of concerns.
Thoughts?

Karl
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Karl Newman]

On Fri, Apr 18, 2008 at 11:14 AM, Tom Hughes <[EMAIL PROTECTED]> wrote:

> In message <[EMAIL PROTECTED]>
>   "Adam Schreiber" <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Apr 18, 2008 at 12:33 PM, Tom Hughes <[EMAIL PROTECTED]> wrote:
> > >  The problem is that we do not have the technology to render different
> > >  countries in different ways. I don't believe we even know of an
> efficient
> > >  way to do it, so we don't even know what the technology would look
> like
> > >  should somebody want to write it.
> >
> > Shouldn't this be as easy as adding a tag indicating country and
> > altering the stylesheet to say highway=motorway country=us =>
> > color=yellow, highway=motorway country=uk => color=blue?
>
> Yes, obviously we could make everybody go round and tag the umpty
> million objects in the database with a country code. That is a pretty
> daft solution though when it should be possible to automate it.
>
> Of course as soon as we'd done that people would start asking for
> the shield shapes to change by state so we'd have to go round and
> add state tags and so on...
>
> Tom
>

Well, the ref tag should already have that information for the US anyway, so
custom shields (and colors) could be done for interstates ("I 5"), US
highways ("US 101"), state highways ("US:CA 12") but probably not county
highways ("CTH 22").

Karl
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Tagging climbing routes and scrambles

[Robin Paulson]

2008/4/18 Steve Hill <[EMAIL PROTECTED]>:
> > structure=pole
> > highway=bus_stop
> > amenity=post_box
> >
>
>  Ok, but you still have a potential conflict here.  Hypothetically, you
> could have a "timetable" tag which applies to both a bus stop (tells you
> when busses arrive) and a post box (when is the post collected?).  A neat
> solution is to have "bus_stop:timetable" and "post_box:timetable".

sorry, i should have made that clearer. i would do this as 3 separate
items, maybe as a relation (slight overkill, but anyway). the relation
would contain 3 nodes, one for the pole, one for the bus stop and one
for the post box. thus each can have it's own timetable without any
confusion. i would never tag one point (or way) as two separate items,
that's asking for trouble, even if the tags don't clash

technically this is wrong (not all 3 nodes can easily share the same
point and still be editable), but i don't see a huge problem in 2 of
them being slightly offset

>
>
>
> > a lot of the disputes over tagging are caused by people confusing
> > physical items with conceptual ones; if we thought about separating
> > them before debating a tagging scheme, things would be a lot clearer
> >
>
>  That may be, but I still think in some cases you are going to want multiple
> conceptual items attached to a single item - namespacing allows this to be
> done without risk of conflicting tags and makes it more obvious how the tags
> interact with each item (conceptual or physical).
>
>  The same thing _could_ be done with relations (i.e. you mark up the
> physical items with ways and nodes and use relations containing physical
> items to represent the conceptial things).  But at the moment that would be
> even more complex than a clear set of namespaces.
>
>
>
>   - Steve
>xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/
>
>  Servatis a periculum, servatis a maleficum - Whisper, Evanescence
>
>

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Too many nodes?

[Ari Torhamo]

la, 2008-04-19 kello 00:32 +0200, Frederik Ramm kirjoitti:

> I think your edits are perfectly ok. Be reminded, though, that we have
> automatic bezier curve hinting in place at least for the "[EMAIL PROTECTED]"
> map, so it is very likely that the road was already a smooth curve on
> the map even before you did your edits.

Bezier hinting doesn't generally seem to work here in Finland yet. The
roads that I edited were definitely unhinted, and all the neighbouring
roads still are. I took a quick look at Helsinki (the capital) too, but
it's rather jaggy there too. I found two ways here in Turku that
apparently are hinted, but not more.

I remember reading this bezier system being planned, but understood that
it wouldn't be nearly ready yet. Is it indeed ready for use, and will it
be the default method for rendering maps? Is it coming to Mapnik too?
What about other renderers? If it will be used for all rendering in the
future, that will make drawing nice curves much easier :-)

Ari Torhamo


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Robert (Jamie) Munro]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tom Hughes wrote:
| In message <[EMAIL PROTECTED]>
| Peter Miller <[EMAIL PROTECTED]> wrote:

|> If we can agree on the rendering rules and get both Mapnik and osmarender
|> sorted out for the USA then people will be incentivised to tag
|> appropriately. The moto 'render and they will come' probably applies
here as
|> elsewhere.
|
| Agreeing on the rules or colour schemes is not the problem.
|
| The problem is that we do not have the technology to render different
| countries in different ways. I don't believe we even know of an efficient
| way to do it, so we don't even know what the technology would look like
| should somebody want to write it.

I don't think this is a problem we shuold be trying to solve. We should
be solving the problem of the tile server only producing 1 rendering.

When I look at the USA, I want interstates to be blue. When an American
looks at the UK, they want to see motorways to be a colour other than
blue, because then they will understand instinctively what kind of road
it is. This should be one of the major benefits of OSM over other maps.

When someone from a USA IP address opens the map, they should see the
USA style tiles by default, but have the UK tiles on the layer switcher.

Robert (Jamie) Munro
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFICSf/z+aYVHdncI0RAsnVAKDQMXTqQ1140PMQj7tqae25Ua3HywCgh9Hu
vgv5+TiMqgD0aaAGyN5T5rg=
=mERT
-END PGP SIGNATURE-

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] GPS accuracy

[Karl Newman]

On Fri, Apr 18, 2008 at 9:05 AM, Jon Stockill <[EMAIL PROTECTED]> wrote:

> Chris Hill wrote:
> > Over last week I've noticed that the accuracy reading on my ETrex has
> briefly gone down to 10ft a few times.  Before last Saturday the best was
> 16ft.  Today I saw 9ft briefly.  Anyone else seen this or know what's going
> on?
>
> I've noticed I've been getting WAAS signals a lot more reliably recently
> - that'll certainly help accuracy. I'm not sure if it's some changes
> that've been made to the GPS sats, or that I've just got better coverage
> in the areas I've mapped recently.
>
> Jon
>

There's a new WAAS satellite that became active in February I think, and
people are reporting better coverage of the east coast of the US and farther
north into Canada. Of course, day to day and even hour to hour your accuracy
will vary depending on the configuration of the satellite constellation.

Karl
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Too many nodes?

[Andy Robinson (blackadder)]

Ari,

The short answer is that you can add as many nodes as you like if you think
it better describes what is physically on the ground. I'm always adding
nodes to stuff to make it look right, but I also remove nodes as I go where
I know or find a feature is truly straight.

Cheers

Andy

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:talk-
>[EMAIL PROTECTED] On Behalf Of Ari Torhamo
>Sent: 18 April 2008 10:22 PM
>To: talk@openstreetmap.org
>Subject: [OSM-talk] Too many nodes?
>
>Hello,
>
>I have a question regarding the amount of nodes that one may use to draw
>a road, and whether the amount of nodes used has a considerable effect
>on the speed of the OpenStreetMap.
>
>I did my first edits to OSM a few days ago. I'll get a GPS device soon,
>but so far my only edits have been adding street names and making roads
>more accurate by adding more nodes to curves, etc. Following these
>edits, another person who has edited the same area earlier, contacted me
>and told me not to add unnecessary nodes to roads that he has made long
>time ago and added that he has already removed the unnecessary nodes.
>According to him using many nodes slows down the rendering and routing.
>
>This made me wonder, what really is the right amount of nodes to use,
>when one want's the curves to be right and look really nice, but not to
>cause any problems by this. Can nodes be added as long as there are
>visible jaggies on the rendered map - even small ones - and just leave
>out the ones which have no affect on rendering (like nodes on a straight
>street)? It would be also good to know, if the speed of rendering and
>routing is a factor that should be concidered? I see now that in a few
>places I added some unnecessary nodes - for example I should have moved
>existing ones instead of adding new ones. Or perhaps I just looked at
>those curves too long - with full zoom - and those jaggies grew up in my
>mind to something bigger than they were :-) On the other hand, in many
>places I think that I made good changes and not many nodes should have
>been removed.
>
>I searched for information on this matter around the OSM web site and
>mailing lists, and found this page (see the section "Accuracy":
>http://wiki.openstreetmap.org/index.php/Editing_Standards_and_Conventions
>I would seem to me that my edits were relatively close to the example
>given there.
>
>I took some screenshots of the changes in question, so that people would
>get a better picture of what I'm talking about. I took screenshots of
>four different places that I edited, and three different versions of
>each of them. The version one shows the situation before my edits, the
>second one after my edits, and the third one after the removal of nodes
>by the original editor. The screenshots are here:
>http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/72157604611934407/
>(note that for some reason Flickr shows the pictures in a reverse
>alphabetical order). The zoomlevel used in the images is 16.
>
>It would be nice to get comments from people who know more about what's
>involved.
>
>
>Regards,
>
>Ari Torhamo
>
>
>___
>talk mailing list
>talk@openstreetmap.org
>http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Too many nodes?

[Frederik Ramm]

Hi,

> I took some screenshots of the changes in question, so that people would
> get a better picture of what I'm talking about. I took screenshots of
> four different places that I edited,

I think your edits are perfectly ok. Be reminded, though, that we have
automatic bezier curve hinting in place at least for the "[EMAIL PROTECTED]"
map, so it is very likely that the road was already a smooth curve on
the map even before you did your edits.

Bye
Frederik

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


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] BBC: Villages 'discovered' in DR Congo

[paul youlten]

Mapping Africa has is likely to be the most challenging - and at the same
time the most valuable - project that OSM contributes to.

Tony Bowden (User:Tmtm) and I are trying to get a pilot project going in
Uganda to help the Guardian's Katine project (
http://www.guardian.co.uk/katine) which is located North East of Soroti (
http://openstreetmap.org/?lat=1.85&lon=33.28&zoom=8&layers=B0FT). The
Guardian is working with local aid agencies to support development in an
area with 66 villages and no access to any up-to-date maps - anyone else
that would like to get involved should email me or leave a message on my
wikipage (User:PaulY).

PaulY


On Fri, Apr 18, 2008 at 1:13 PM, Matt Williams <[EMAIL PROTECTED]> wrote:

> It seems the DR Congo has been mapping their villages using GPS devices
> since
> traditional mapping methods are made difficult by the thick forest. See
> the
> BBC article: http://news.bbc.co.uk/1/hi/world/africa/7355335.stm.
>
> Compare their map
>
> http://news.bbc.co.uk/1/shared/spl/hi/pop_ups/08/africa_enl_1208537563/html/1.stm
> to our's at present
> http://openstreetmap.org/?lat=-2.017&lon=17.117&zoom=9&layers=B0FT.
>
> Does anyone have any more information about this?
>
> Regards,
> Matt Williams
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>
>


-- 
Tel: +44(0) 7814 517 807
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] BBC: Villages 'discovered' in DR Congo

[Peter Miller]

> Message: 7
> Date: Fri, 18 Apr 2008 21:13:12 +0100
> From: Matt Williams <[EMAIL PROTECTED]>
> Subject: [OSM-talk] BBC: Villages 'discovered' in DR Congo
> To: talk 
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="us-ascii"
> 
> It seems the DR Congo has been mapping their villages using GPS devices
> since
> traditional mapping methods are made difficult by the thick forest. See
> the
> BBC article: http://news.bbc.co.uk/1/hi/world/africa/7355335.stm.
> 
> Compare their map
> http://news.bbc.co.uk/1/shared/spl/hi/pop_ups/08/africa_enl_1208537563/htm
> l/1.stm
> to our's at present
> http://openstreetmap.org/?lat=-2.017&lon=17.117&zoom=9&layers=B0FT.
> 
> Does anyone have any more information about this?
> 
> Regards,
> Matt Williams

Fyi, I saw the article earlier this evening and have already emailed someone
in the oganisation to tell them about OSM and ask if we can help them or if
they can provide their data to us for someone  in our community to enter on
their behalf.

Regards,


Peter



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Jon Burgess]

On Fri, 2008-04-18 at 21:57 +0100, Jon Burgess wrote:
> It should then be possible to include fips_cntry as a filter in the
> osm.xml. 

>From a purely functional perspective this approach seems to work. The
screenshot below shows what happens if you ask for the motorways in
Ireland to be rendered in purple:

http://tile.openstreetmap.org/direct/country-mways-example.png

The motorways in England and Northern Ireland still render in the
default blue.

Jon



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] Too many nodes?

[Ari Torhamo]

Hello,

I have a question regarding the amount of nodes that one may use to draw
a road, and whether the amount of nodes used has a considerable effect
on the speed of the OpenStreetMap.

I did my first edits to OSM a few days ago. I'll get a GPS device soon,
but so far my only edits have been adding street names and making roads
more accurate by adding more nodes to curves, etc. Following these
edits, another person who has edited the same area earlier, contacted me
and told me not to add unnecessary nodes to roads that he has made long
time ago and added that he has already removed the unnecessary nodes.
According to him using many nodes slows down the rendering and routing.

This made me wonder, what really is the right amount of nodes to use,
when one want's the curves to be right and look really nice, but not to
cause any problems by this. Can nodes be added as long as there are
visible jaggies on the rendered map - even small ones - and just leave
out the ones which have no affect on rendering (like nodes on a straight
street)? It would be also good to know, if the speed of rendering and
routing is a factor that should be concidered? I see now that in a few
places I added some unnecessary nodes - for example I should have moved
existing ones instead of adding new ones. Or perhaps I just looked at
those curves too long - with full zoom - and those jaggies grew up in my
mind to something bigger than they were :-) On the other hand, in many
places I think that I made good changes and not many nodes should have
been removed.

I searched for information on this matter around the OSM web site and
mailing lists, and found this page (see the section "Accuracy":
http://wiki.openstreetmap.org/index.php/Editing_Standards_and_Conventions
I would seem to me that my edits were relatively close to the example
given there.

I took some screenshots of the changes in question, so that people would
get a better picture of what I'm talking about. I took screenshots of
four different places that I edited, and three different versions of
each of them. The version one shows the situation before my edits, the
second one after my edits, and the third one after the removal of nodes
by the original editor. The screenshots are here:
http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/72157604611934407/
(note that for some reason Flickr shows the pictures in a reverse
alphabetical order). The zoomlevel used in the images is 16.

It would be nice to get comments from people who know more about what's
involved.


Regards,

Ari Torhamo


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Frederik Ramm]

Hi,

> I really don't mind what the rendered colours are, that is for local
> discussion and there may even be multiple versions with different styles
> as far as I am concerned

Agree.

> but currently the rendering is uk-centric 

Which comes as no surprise given that the project was started in the
UK and most of the people involved in rendering live there.

> and that seems inappropriate for the USA and seems to be causing
> distortions with tagging.

This last point is a bit difficult to understand for me. Over here in
Germany, nobody would draw their motorways in blue or their trunk
roads in green, ever. But to my knowledge, no mapper as ever reacted
by tagging his motorways "secondary" only to get the "right" colour!

We have often said that providing *maps* is not our main business -
collecting data is. We only do maps to show off what we have. So I'd
agree with those who say why not let the Americans, and anyone else
who is unhappy, set up their own tile server? We'll surely do that for
Germany sooner or later, too.

Bye
Frederik

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


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Jon Burgess]

On Fri, 2008-04-18 at 20:02 +0100, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
>   Jon Burgess <[EMAIL PROTECTED]> wrote:
> 
> > Provided we have the polygons describing the boundaries of countries,
> > states etc then we could tag the data during the osm2pgsql processing.
> > Alternatively it might be possible for Mapnik to query them at run time
> > (with the right join to a table containing boundary polygons in the data
> > source SELECT line it might even be possible today).
> 
> I was thinking about that while I was walking home earlier. The
> main question I guess is how efficient PostGIS is at answering
> the question "which of these N hundred polygons is this data
> in", or how efficiently we can code the equivalent in osm2pgsql.

This is a valid concern. Having more than one table in the select seems
to confuse mapnik (possibly because it has trouble locating the correct
geometry column for the query). 

I seem to be getting a reasonable result by adding a country column into
the DB after the import.

Importing the world_boundaries_m.shp polygon into postgis:

$ shp2pgsql -s 900913 -I -g border world_boundaries_m boundaries | psql -q gis

[ this srid is wrong, it should probably be 3365 but it is close enough
for this test and saves having to deal with transforming geometries ]

Then create a new table with data derived from the roads but with an
extra column added for the country:

gis=> create table c_roads as select
planet_osm_roads.*,boundaries.fips_cntry from planet_osm_roads,
boundaries where way && border and within(way, border);
SELECT
Time: 139292.756 ms

The above is for the UK subset of the planet and 2 minutes seems fairly
reasonable. The line table has about 6 times the data so would be much
slower. As long as the country specific rendering is restricted to
motorway/trunk/primary/secondary roads then the planet_osm_roads table
is all we need to process.

Then a quick test counting the number of roads per country:
gis=> select fips_cntry,count(*) as num from c_roads group by fips_cntry order 
by num desc;
 fips_cntry |  num
+---
 UK | 74199
 EI |  2582
 FR |   703
 IM |   199
(4 rows)

The above results seem reasonable given that this is against a UK planet
subset which includes small bits of France, Ireland etc.

It should then be possible to include fips_cntry as a filter in the
osm.xml. 

We'll have to see whether this scales to cope with the whole planet file
and polygons for every county/state/province etc.

> > My main concern would be the maintainability of the osm.xml style file.
> > It is already nearing 200kB and adding country (or state) specific
> > rendering would make it even more complex.
> 
> Indeed. I was thinking about that too, and I think it needs an
> extrat level of indirection, so the existing stylesheet stays
> largely as it is but instead of saying that a secondary road
> is rendered as #213455 or whatever some sort of code name is
> given and then that is mapped to the real colour based on the
> country.

I believe Artem proposed something similar to me once before but wanted
the feature code to be derived during the osm2pgsql import. This has the
benefit of making the rendering faster but it means that you have to
make the decision of how to categorise every feature at import time
which removes some flexibility from the osm.xml file (who knows, maybe
this is a good thing :-).

Jon



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Martijn van Oosterhout]

On Fri, Apr 18, 2008 at 9:02 PM, Tom Hughes <[EMAIL PROTECTED]> wrote:
>  I was thinking about that while I was walking home earlier. The
>  main question I guess is how efficient PostGIS is at answering
>  the question "which of these N hundred polygons is this data
>  in", or how efficiently we can code the equivalent in osm2pgsql.

Getting osm2pgsql to do it on insert wouldn't be too hard once you
have a table of polygon. Biggest problem is going to be that it's
going to slow everything down a lot.

However, when we get so far that osm2pgsql can process just diffs,
then you only have to do it once and after that the load will be quite
managable...

>  Indeed. I was thinking about that too, and I think it needs an
>  extrat level of indirection, so the existing stylesheet stays
>  largely as it is but instead of saying that a secondary road
>  is rendered as #213455 or whatever some sort of code name is
>  given and then that is mapped to the real colour based on the
>  country.

Yeah, either mapnik needs to handle this (perhaps some kind of lookup
table indirection), or we have a script that takes the current sheet
and a list of (country code,tag,colour) and produces a much bigger
file with all the changes...

Have a nice day,
-- 
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Cartinus]

On Friday 18 April 2008 21:23:47 Peter Miller wrote:
> The answer is that OSM's currently
> colour scheme seems to be that it is UK imperialism!
>
> For interest, here are some colours using by Google maps around the world

> I would suggest we have a default of orange for top-level roads everywhere
> with a local override which is blue for the UK and other countries can
> debate what they want would be idea.

I would suggest we don't change the colours on the default OSM map at all. And 
especially not to some US / Google imperialist global uniform style.

If I buy a paper map from Michelin, another one from Kümmerly+Frey and a third 
from Falkplan, then I don't expect them to all have the same style. Why would 
all electronic maps need to look the same?

There is a really simple technical solution to have a national render style 
for OSM maps. Setup your own national tile server. Like the Dutch tile server 
and IIRC there is one for Japan too. This has the additional benefit it 
spreads the load over more servers.


-- 
m.v.g.,
Cartinus

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] BBC: Villages 'discovered' in DR Congo

[Matt Williams]

It seems the DR Congo has been mapping their villages using GPS devices since 
traditional mapping methods are made difficult by the thick forest. See the 
BBC article: http://news.bbc.co.uk/1/hi/world/africa/7355335.stm.

Compare their map 
http://news.bbc.co.uk/1/shared/spl/hi/pop_ups/08/africa_enl_1208537563/html/1.stm
 
to our's at present 
http://openstreetmap.org/?lat=-2.017&lon=17.117&zoom=9&layers=B0FT. 

Does anyone have any more information about this?

Regards,
Matt Williams


signature.asc
Description: This is a digitally signed message part.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] tagging and rendering highways in the USA and elsewhere

[Peter Miller]

> Date: Fri, 18 Apr 2008 13:44:49 -0400
> From: "Adam Schreiber" <[EMAIL PROTECTED]>
> Subject: Re: [OSM-talk] tagging and rendering highways in the USA and
>   elsewhere
> To: "Tom Hughes" <[EMAIL PROTECTED]>
> Cc: talk@openstreetmap.org
> Message-ID:
>   <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=UTF-8
> 
> On Fri, Apr 18, 2008 at 12:33 PM, Tom Hughes <[EMAIL PROTECTED]> wrote:
> >  The problem is that we do not have the technology to render different
> >  countries in different ways. I don't believe we even know of an
> efficient
> >  way to do it, so we don't even know what the technology would look like
> >  should somebody want to write it.
> 
> Shouldn't this be as easy as adding a tag indicating country and
> altering the stylesheet to say highway=motorway country=us =>
> color=yellow, highway=motorway country=uk => color=blue?
>

I think tagging each way with the country puts huge additional work onto
every mapper. We should have boundaries for countries from somewhere I
believe, and that will provide the national context for default rendering.
Possibly it is not achievable immediately, but I suggest we need to solve it
and ensure the integrity of the tagging in the meantime.

As to the question about 'who decides on the actual rendering' I am not
personally sure and it may require a bit of a benevolent dictator role in
the end, however if the core tagging is clear and consistent across OSM
then anyone is free to do their own rendering.

To answer the question about who chose blue for motorways. That is a
standard across road-maps in the UK that was possibly defined with motorways
were first build in the UK. I have a UK road atlas from 1976 that has the
motorways in blue. I guess that red was used for the most important roads
(being a bright colour) with a tone spreading from yellow through orange to
red before motorways and then when someone invented a new more important one
a new colour was needed. The answer is that OSM's currently colour scheme
seems to be that it is UK imperialism!

For interest, here are some colours using by Google maps around the world
for motorways or their local equitant.

Orange: USA, Canada, Germany, Russia, India, China
Red: Australia, France
Blue: UK


And for Yahoo

Red: USA, France, Russia
Orange: India
Blue: UK

And for Microsoft (local.live)

Green: France
Orange: UK, India, China
Yellow: Russia


So actually it is all a bit fluid and variable, but I still think a table
for colours by county makes sense unless someone wants to get agreement on a
single colour.

I would suggest we have a default of orange for top-level roads everywhere
with a local override which is blue for the UK and other countries can
debate what they want would be idea.

In the mean time please can we strongly encourage consistent tagging of
highways everywhere.

Regards,



Peter
 
> Cheers,
> 
> Adam
> 
> 



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Tom Hughes]

In message <[EMAIL PROTECTED]>
  Jon Burgess <[EMAIL PROTECTED]> wrote:

> Provided we have the polygons describing the boundaries of countries,
> states etc then we could tag the data during the osm2pgsql processing.
> Alternatively it might be possible for Mapnik to query them at run time
> (with the right join to a table containing boundary polygons in the data
> source SELECT line it might even be possible today).

I was thinking about that while I was walking home earlier. The
main question I guess is how efficient PostGIS is at answering
the question "which of these N hundred polygons is this data
in", or how efficiently we can code the equivalent in osm2pgsql.

> My main concern would be the maintainability of the osm.xml style file.
> It is already nearing 200kB and adding country (or state) specific
> rendering would make it even more complex.

Indeed. I was thinking about that too, and I think it needs an
extrat level of indirection, so the existing stylesheet stays
largely as it is but instead of saying that a secondary road
is rendered as #213455 or whatever some sort of code name is
given and then that is mapped to the real colour based on the
country.

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Matt Williams]

On Friday 18 April 2008 19:25:37 Peter Miller wrote:
> I hope I didn't come across as aggressive, but I did want to point out some
> really weird inconsistencies that do need to be resolved and wanted to
> encourage debate. In the UK a secondary roads is a minor road, in San
> Francisco this
> 
> junction (a multilevel road with multiple flyovers) is classed as secondary
> whereas this
>   one
> (an urban road with traffic signal controlled junctions) is classed as
> primary.
>
>
>
> I suspect that fact reason that the first is classed as secondary is
> because the mapper wanted an orange road and that it should really be a
> 'trunk' road.
>
>
>
> I really don't mind what the rendered colours are, that is for local
> discussion and there may even be multiple versions with different styles as
> far as I am concernedm, but currently the rendering is uk-centric and that
> seems inappropriate for the USA and seems to be causing distortions with
> tagging.

I think most people agree with that, but as said, there's a technological 
barrier to overcome.

> I do think that the hierarchy of road classes needs to be respected across
> OSM (where a trunk road is more important than primary road than secondary
> road etc) allowing a routing engine to direct drivers worldwide onto the
> main routes (and also possibly keep pedestrians and cyclists off them). I
> do think that the '_link' element needs to be used to help sat-nav systems
> give meaningful instructions and not give out information about turning
> onto link roads when it should say 'turn onto Highway 101'. I do think the
> description of the highway road classes in Map Features needs to be
> internationalised to allow people in new countries to chose the right
> mapping to their own infrastructure and naming and colour conventions.

It already is. See 
http://wiki.openstreetmap.org/index.php/Key:highway#International_equivalence 
for the current definitions.

Regards,
Matt Williams

> Personally I hope that San Francisco will prove a useful test case where
> many of the outstanding internationalisation issues can be bottomed out
> before there before large scale tagging across many other parts of the
> country.
>
>
>
> Currently everything except interstate is tagged as 'residential'. If it
> was agreed that state highways should be 'trunk' roads then would it be
> sensible to design a 'bot' to scan un-touched tiger data for road names
> including the word 'state' but not the word 'interstate' and automatically
> update the tags from 'highway=residential' to 'highway=trunk' (or whatever
> is agreed).


signature.asc
Description: This is a digitally signed message part.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Jon Burgess]

On Fri, 2008-04-18 at 19:14 +0100, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
>   "Adam Schreiber" <[EMAIL PROTECTED]> wrote:
> 
> > On Fri, Apr 18, 2008 at 12:33 PM, Tom Hughes <[EMAIL PROTECTED]> wrote:
> > >  The problem is that we do not have the technology to render different
> > >  countries in different ways. I don't believe we even know of an efficient
> > >  way to do it, so we don't even know what the technology would look like
> > >  should somebody want to write it.
> > 
> > Shouldn't this be as easy as adding a tag indicating country and
> > altering the stylesheet to say highway=motorway country=us =>
> > color=yellow, highway=motorway country=uk => color=blue?
> 
> Yes, obviously we could make everybody go round and tag the umpty
> million objects in the database with a country code. That is a pretty
> daft solution though when it should be possible to automate it.
> 
> Of course as soon as we'd done that people would start asking for
> the shield shapes to change by state so we'd have to go round and
> add state tags and so on...
> 
> Tom

Provided we have the polygons describing the boundaries of countries,
states etc then we could tag the data during the osm2pgsql processing.
Alternatively it might be possible for Mapnik to query them at run time
(with the right join to a table containing boundary polygons in the data
source SELECT line it might even be possible today).

Generating the appropriate polygons from OSM data would be another
challenge for the reader. Using an external tool like the one used for
coastline shapefile generator is probably the answer.

My main concern would be the maintainability of the osm.xml style file.
It is already nearing 200kB and adding country (or state) specific
rendering would make it even more complex.

Jon




___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Matt Williams]

On Friday 18 April 2008 19:14:22 Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
>
>   "Adam Schreiber" <[EMAIL PROTECTED]> wrote:
> > On Fri, Apr 18, 2008 at 12:33 PM, Tom Hughes <[EMAIL PROTECTED]> wrote:
> > >  The problem is that we do not have the technology to render different
> > >  countries in different ways. I don't believe we even know of an
> > > efficient way to do it, so we don't even know what the technology would
> > > look like should somebody want to write it.
> >
> > Shouldn't this be as easy as adding a tag indicating country and
> > altering the stylesheet to say highway=motorway country=us =>
> > color=yellow, highway=motorway country=uk => color=blue?
>
> Yes, obviously we could make everybody go round and tag the umpty
> million objects in the database with a country code. That is a pretty
> daft solution though when it should be possible to automate it.
>
> Of course as soon as we'd done that people would start asking for
> the shield shapes to change by state so we'd have to go round and
> add state tags and so on...

Well in that case it wouldn't be unfeasible to add is_in=Texas to the highways 
and in fact, "is_in=" is clearly better than "country=" anyway. But you're 
right, for country-wide location ionformation, it _should_ be possible to 
automate.

Regards,
Mat Williams


signature.asc
Description: This is a digitally signed message part.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Peter Miller]

I hope I didn't come across as aggressive, but I did want to point out some
really weird inconsistencies that do need to be resolved and wanted to
encourage debate. In the UK a secondary roads is a minor road, in San
Francisco this

junction (a multilevel road with multiple flyovers) is classed as secondary
whereas this
  one
(an urban road with traffic signal controlled junctions) is classed as
primary.

 

I suspect that fact reason that the first is classed as secondary is because
the mapper wanted an orange road and that it should really be a 'trunk'
road.

 

I really don't mind what the rendered colours are, that is for local
discussion and there may even be multiple versions with different styles as
far as I am concernedm, but currently the rendering is uk-centric and that
seems inappropriate for the USA and seems to be causing distortions with
tagging.

 

I do think that the hierarchy of road classes needs to be respected across
OSM (where a trunk road is more important than primary road than secondary
road etc) allowing a routing engine to direct drivers worldwide onto the
main routes (and also possibly keep pedestrians and cyclists off them). I do
think that the '_link' element needs to be used to help sat-nav systems give
meaningful instructions and not give out information about turning onto link
roads when it should say 'turn onto Highway 101'. I do think the description
of the highway road classes in Map Features needs to be internationalised to
allow people in new countries to chose the right mapping to their own
infrastructure and naming and colour conventions.

 

Personally I hope that San Francisco will prove a useful test case where
many of the outstanding internationalisation issues can be bottomed out
before there before large scale tagging across many other parts of the
country.

 

Currently everything except interstate is tagged as 'residential'. If it was
agreed that state highways should be 'trunk' roads then would it be sensible
to design a 'bot' to scan un-touched tiger data for road names including the
word 'state' but not the word 'interstate' and automatically update the tags
from 'highway=residential' to 'highway=trunk' (or whatever is agreed).

 

 

Regards,

 

 

 

 

Peter

 

> -Original Message-

> From: Andy Allan [mailto:[EMAIL PROTECTED]

> Sent: 18 April 2008 17:38

> To: Peter Miller

> Cc: Talk Openstreetmap

> Subject: Re: [OSM-talk] tagging and rendering highways in the USA and

> elsewhere

> 

> > If we can agree on the rendering rules and get both Mapnik and

> osmarender

> > sorted out for the USA

> 

> "sorted out" - they both work fine. Even if we had a production-ready

> mechanism for country-specific rendering, it would still be a matter

> of opinion, or more accurately, a matter of cartographic style, as to

> whether we want to render the freeways in orange. After all, it's just

> a map, and conventions are only conventions, not hard and fast rules.

> 

> Not saying that we shouldn't, just that your phrasing is quite

> aggressive for what is a matter of taste. I wouldn't want someone to

> say that my choice of colours for the cycle map contours needs

> "sorting out" (even if that might well be true!).

> 

> Cheers,

> Andy

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Tom Hughes]

In message <[EMAIL PROTECTED]>
  Ben Laenen <[EMAIL PROTECTED]> wrote:

> On Friday 18 April 2008, Tom Hughes wrote:
> > > If we can agree on the rendering rules and get both Mapnik and
> > > osmarender sorted out for the USA then people will be incentivised
> > > to tag appropriately. The moto 'render and they will come' probably
> > > applies here as elsewhere.
> >
> > Agreeing on the rules or colour schemes is not the problem.
> 
> Who decides what colours are used on the main maps? I.e. who actually
> decided that motorways should be blue, and trunks should be green, how
> railways are rendered etc.?

The people who are sufficiently interested to get involved with making
changes to the stylesheets.

> Say I'd like to see railways rendered differently in the [EMAIL PROTECTED] 
> maps, where
> should I ask? Is there some "formal" process like for accepting new
> tags where general agreement is formed?

The question of what tags are used is orthogonal to how things are
rendered - not every rendering will show every object to start with.

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Tom Hughes]

In message <[EMAIL PROTECTED]>
  "Adam Schreiber" <[EMAIL PROTECTED]> wrote:

> On Fri, Apr 18, 2008 at 12:33 PM, Tom Hughes <[EMAIL PROTECTED]> wrote:
> >  The problem is that we do not have the technology to render different
> >  countries in different ways. I don't believe we even know of an efficient
> >  way to do it, so we don't even know what the technology would look like
> >  should somebody want to write it.
> 
> Shouldn't this be as easy as adding a tag indicating country and
> altering the stylesheet to say highway=motorway country=us =>
> color=yellow, highway=motorway country=uk => color=blue?

Yes, obviously we could make everybody go round and tag the umpty
million objects in the database with a country code. That is a pretty
daft solution though when it should be possible to automate it.

Of course as soon as we'd done that people would start asking for
the shield shapes to change by state so we'd have to go round and
add state tags and so on...

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Adam Schreiber]

On Fri, Apr 18, 2008 at 2:02 PM, Frederik Ramm <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
>  > Shouldn't this be as easy as adding a tag indicating country and
>  > altering the stylesheet to say highway=motorway country=us =>
>  > color=yellow, highway=motorway country=uk => color=blue?
>
>  Complete with the ability to have US motorways in the UK, yay!

Authentication of the data is a different problem than rendering it.

Note that this is different than tagging for a renderer since the data
country=foo is real and not a hint.  It was also just an example, not
necessarily an actual tagging suggestion.  The example was presented
because there was an assertion that it was a technological problem.

Adam

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Frederik Ramm]

Hi,

> Who decides what colours are used on the main maps? I.e. who actually 
> decided that motorways should be blue, and trunks should be green, how 
> railways are rendered etc.?
> 
> Say I'd like to see railways rendered differently in the [EMAIL PROTECTED] 
> maps, where 
> should I ask? Is there some "formal" process like for accepting new 
> tags where general agreement is formed?

The [EMAIL PROTECTED] maps are computed based on stylesheets that are in SVN, so
anybody can change them. It usually takes a while until a change is
visible everywhere because (1) not all tiles are rendered anew after a
style change, and (2) not all renderers update their styles every day.

We don't have a formal process to decide nor are there written rules.
The unwritten rules are probably roughly:

1. Don't break the styles
2. If you add something that affects only a small number of tiles,
   say because you started to tag historic battle sites and want a
   little marker there at the highest zoom level, just do it - if 
   people are unhappy, they can still change it and re-render
3. If you want to change something big, then discuss it on the [EMAIL PROTECTED]
   list. It's no use pushing through a change that would lead to
   half of the renderers simply refusing to update ;-)
4. Big changes like a different colour for highways are a bit 
   difficult since very many tiles have to be rendered, and the map
   will be a patchwork of old and new tiles for quite a while.

Bye
Frederik

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


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Frederik Ramm]

Hi,

> Shouldn't this be as easy as adding a tag indicating country and
> altering the stylesheet to say highway=motorway country=us =>
> color=yellow, highway=motorway country=uk => color=blue?

Complete with the ability to have US motorways in the UK, yay!

Bye
Frederik

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


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Adam Schreiber]

On Fri, Apr 18, 2008 at 12:33 PM, Tom Hughes <[EMAIL PROTECTED]> wrote:
>  The problem is that we do not have the technology to render different
>  countries in different ways. I don't believe we even know of an efficient
>  way to do it, so we don't even know what the technology would look like
>  should somebody want to write it.

Shouldn't this be as easy as adding a tag indicating country and
altering the stylesheet to say highway=motorway country=us =>
color=yellow, highway=motorway country=uk => color=blue?

Cheers,

Adam

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Ben Laenen]

On Friday 18 April 2008, Tom Hughes wrote:
> > If we can agree on the rendering rules and get both Mapnik and
> > osmarender sorted out for the USA then people will be incentivised
> > to tag appropriately. The moto 'render and they will come' probably
> > applies here as elsewhere.
>
> Agreeing on the rules or colour schemes is not the problem.

Who decides what colours are used on the main maps? I.e. who actually 
decided that motorways should be blue, and trunks should be green, how 
railways are rendered etc.?

Say I'd like to see railways rendered differently in the [EMAIL PROTECTED] 
maps, where 
should I ask? Is there some "formal" process like for accepting new 
tags where general agreement is formed?

Greetings
Ben

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Tagging climbing routes and scrambles

[Andy Allan]

On Fri, Apr 18, 2008 at 3:05 PM, Steve Hill <[EMAIL PROTECTED]> wrote:

>  Actually, I would prefer to see everything namespaced, such as
> amenity:pub:name or pub:name.

Hmm. In that case, I'm not sure we'll see eye to eye on this at any point!

Cheers,
Andy

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Tagging climbing routes and scrambles

[Andy Allan]

On Fri, Apr 18, 2008 at 2:58 PM, Tom Hughes <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>
>
> Andy Allan <[EMAIL PROTECTED]> wrote:
>
>  > Ah, I see the problem. You are taking a tag away from it's context,
>  > and then complaining that the tag has no context on its own. Only part
>  > of your argument is based around conflicts, but the rest seems to be
>  > context.
>  >
>  > How do I tell that name="The Duke's Head" refers to the name of a pub?
>  > I don't feel the need for amenity:pub:name= and highway:primary:name=
>  > in order to solve this issue. Instead, I examine the context of the
>  > original tag, and find that it is the name of a pub.
>
>  Because the name tag is always the name of an object, regardless of
>  what that object is (the amenity=pub tells you what sort of object it
>  is in this case). It is clear to everybody that a name tag is going
>  to tell you the name of something without having to know anything else
>  about it.
>
>  It is not clear to anybody outside a very specific community what
>  a tag called "french" is likely to mean.

Maybe "french" is a bad choice, and is colouring the discussion too
much. I don't think this choice of tag warrants namespaces though.

I look at the proposed "climbing:rock=limestone" and wonder to what
possible information the 'climbing' conveys, other than needless
typing. Surely it's just rock=limestone?

Cheers,
Andy

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] osmxapi/bbox question

[80n]

On Fri, Apr 18, 2008 at 4:56 PM, Frederik Ramm <[EMAIL PROTECTED]> wrote:

> Hi,
>
>  That way you can call the osmxapi url with [polygon=belgium] or
> > > [polygon:country=belgium]
> > >
> > > What do the osmxapi developers think about it?
> > >
> > >
> > It's a nice idea.  I just need to implement the algorithm described
> > earlier
> > in this thread :)
> >
>
> Not only do you need to implement the algorithm, you also need a computing
> environment that will be able to execute the algorithm in an acceptable
> timeframe. A halfway "correct" border polygon of a landlocked state easily
> runs into five-digit numbers of polygon nodes, and then for each of the 250
> million nodes in the database, you have to find out whether it lies in that
> polygon.
>
> (An obvious optimization is to compute the largest rectangle contained in,
> and the largest rectangle containing, the polygon. First check if point is
> outside the outer bbox - if yes, you're done. Then check if point is inside
> the inner bbox - if yes, you're done. Only after that do the actual polygon
> test.)
>

Yes, the algorithm is simple, it's implementation is a little more
challenging.



>
> Bye
> Frederik
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] GPS accuracy

[Andy Robinson (blackadder)]

Chris Hill wrote:
>Sent: 18 April 2008 4:24 PM
>To: Talk OSM
>Subject: [OSM-talk] GPS accuracy
>
>Over last week I've noticed that the accuracy reading on my ETrex has
>briefly gone down to 10ft a few times.  Before last Saturday the best was
>16ft.  Today I saw 9ft briefly.  Anyone else seen this or know what's going
>on?

If WASS support is turned on (EGNOS for those in Europe although the eTrex
still calls it WASS) and its able to see the stationary SBAS satellite(s)
over the equator then the eTrex should give you accuracy values on the
screen of 2m to 6m so almost certainly values below 16 feet are having WASS
corrections applied.

I did note that the recent firmware upgrade to many of the eTrex range that
came out at the end of March had a WASS component, no idea if that's made a
difference or not.

Be wary about the number quoted on the eTrex though. Just because it says
its accuracy is 9 feet doesn't mean to say you are within 9 feet from the
expected position. It's a guide but not in practice a precise value.

Cheers

Andy

>
>cheers, Chris
>
>
>
>
>  __
>Sent from Yahoo! Mail.
>A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
>
>
>___
>talk mailing list
>talk@openstreetmap.org
>http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USAandelsewhere

[Dan Putler]

On a "ground truth" note, it turns out that state "highways" in
California do range from freeways (CA 85), to major urban surface roads
(CA 82) to narrow two-lane rural roads (CA 130). While "lowly", some of
them really are secondary roads.

Dan
 
On Fri, 2008-04-18 at 17:33 +0100, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Peter Miller <[EMAIL PROTECTED]> wrote:
> 
> > The state roads are currently tagged on OSM variously with trunk (green)
> > primary (red) and secondary (orange). Some pretty major roads a tagged with
> > secondary (actually a very lowly road class in the UK below motorway, trunk
> > and primary) and I suspect that this is because it renders with the correct
> > colour. There is no 'secondary_link' tag for exit and entrance ramps because
> > secondary roads are too minor to have such things so highways rendered as
> > secondary are using 'secondary' tags for exist and entrance ramps as well.
> 
> There is no such thing as a tag that does not exist in OSM as we have
> freeform tagging. In addition to which mapnik at least does render
> things marked as secondary_link, so it seems to do a pretty good
> impression of something that exists to me.
> 
> > If we can agree on the rendering rules and get both Mapnik and osmarender
> > sorted out for the USA then people will be incentivised to tag
> > appropriately. The moto 'render and they will come' probably applies here as
> > elsewhere.
> 
> Agreeing on the rules or colour schemes is not the problem.
> 
> The problem is that we do not have the technology to render different
> countries in different ways. I don't believe we even know of an efficient
> way to do it, so we don't even know what the technology would look like
> should somebody want to write it.
> 
> See the ongoing discussion about the difficulty of the problem of
> determining efficiently what country something lies in for what I'm
> talking about.
> 
> Tom
> 
-- 
Dan Putler
Sauder School of Business
University of British Columbia


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Andy Allan]

> If we can agree on the rendering rules and get both Mapnik and osmarender
> sorted out for the USA

"sorted out" - they both work fine. Even if we had a production-ready
mechanism for country-specific rendering, it would still be a matter
of opinion, or more accurately, a matter of cartographic style, as to
whether we want to render the freeways in orange. After all, it's just
a map, and conventions are only conventions, not hard and fast rules.

Not saying that we shouldn't, just that your phrasing is quite
aggressive for what is a matter of taste. I wouldn't want someone to
say that my choice of colours for the cycle map contours needs
"sorting out" (even if that might well be true!).

Cheers,
Andy

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

[Tom Hughes]

In message <[EMAIL PROTECTED]>
Peter Miller <[EMAIL PROTECTED]> wrote:

> The state roads are currently tagged on OSM variously with trunk (green)
> primary (red) and secondary (orange). Some pretty major roads a tagged with
> secondary (actually a very lowly road class in the UK below motorway, trunk
> and primary) and I suspect that this is because it renders with the correct
> colour. There is no 'secondary_link' tag for exit and entrance ramps because
> secondary roads are too minor to have such things so highways rendered as
> secondary are using 'secondary' tags for exist and entrance ramps as well.

There is no such thing as a tag that does not exist in OSM as we have
freeform tagging. In addition to which mapnik at least does render
things marked as secondary_link, so it seems to do a pretty good
impression of something that exists to me.

> If we can agree on the rendering rules and get both Mapnik and osmarender
> sorted out for the USA then people will be incentivised to tag
> appropriately. The moto 'render and they will come' probably applies here as
> elsewhere.

Agreeing on the rules or colour schemes is not the problem.

The problem is that we do not have the technology to render different
countries in different ways. I don't believe we even know of an efficient
way to do it, so we don't even know what the technology would look like
should somebody want to write it.

See the ongoing discussion about the difficulty of the problem of
determining efficiently what country something lies in for what I'm
talking about.

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] tagging and rendering highways in the USA and elsewhere

[Peter Miller]

It would be good to get a resolution of the issue of highway classification
and rendering in the USA.

 

The San Francisco area is getting into a pretty

good state now, and could act as an 'exemplar' area for the USA should good
tagging practice, however the current highway tagging and rendering is a
mess and also looks wrong on the final map.

 

 I realise a bunch of you are meeting tomorrow in San Francisco for a
mapping party tomorrow so though I would chuck in my thoughts first.

 

 

 

The interstate roads are currently tagged 'motorway' and rendered blue.

 

The state roads are currently tagged on OSM variously with trunk (green)
primary (red) and secondary (orange). Some pretty major roads a tagged with
secondary (actually a very lowly road class in the UK below motorway, trunk
and primary) and I suspect that this is because it renders with the correct
colour. There is no 'secondary_link' tag for exit and entrance ramps because
secondary roads are too minor to have such things so highways rendered as
secondary are using 'secondary' tags for exist and entrance ramps as well.

 

With the current rendering people will be tempted to tag major roads as
'secondary' and get everthing into a bit of mess although others will insist
on using the hierarchy correctly and ignore the non-standard colour of the
resulting map.

 

 

Can I propose the following:

 

Interstate should be tagged 'motorway' and be rendered orange with a rather
grand rendering of the route number as on Google maps and on other US maps.

 

Major non-interstate highways that have traffic light free multi-level
junctions etc should be tagged as 'trunk' and possibly also be rendered
orange but with less grand route numbers to differentiate them from
interstate routes.

 

Major routes with multi lane traffic (2+lanes in each direction) but which
stop for traffic signals and have random side roads coming in frequently are
tagged 'primary' and should appear yellow and be reasonable wide.

 

Secondary and tertiary and then available for lower tiers and should appear
as yellow but be narrower.

 

If we can agree on the rendering rules and get both Mapnik and osmarender
sorted out for the USA then people will be incentivised to tag
appropriately. The moto 'render and they will come' probably applies here as
elsewhere.

 

Can I suggest that you do some block changes to the highways tags over the
weekend to get the tags right and (of course the colours will then be wrong)
ie top roads motorway/motorway_link=blue, next level trunk/trunk_link=green,
next level primary/primary_link=red and finally secondary=orange and
tertiary=yellow and then ensure that the rendering rules get sorted for
osmarender and mapnik .

 

Btw, I am not on the talk-us list. I will look and he USA list on the web
from time to time but so do include me in any relevant responses. I am
copying this to the main list because I suspect the issue also applies to
other countries around the world.

 

 

 

Regards,

 

 

 

Peter Miller

 

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] GPS accuracy

[Jon Stockill]

Chris Hill wrote:
> Over last week I've noticed that the accuracy reading on my ETrex has briefly 
> gone down to 10ft a few times.  Before last Saturday the best was 16ft.  
> Today I saw 9ft briefly.  Anyone else seen this or know what's going on?

I've noticed I've been getting WAAS signals a lot more reliably recently 
- that'll certainly help accuracy. I'm not sure if it's some changes 
that've been made to the GPS sats, or that I've just got better coverage 
in the areas I've mapped recently.

Jon

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] osmxapi/bbox question

[Andy Allan]

On Fri, Apr 18, 2008 at 4:56 PM, Frederik Ramm <[EMAIL PROTECTED]> wrote:

>  (An obvious optimization is to compute the largest rectangle contained
>  in, and the largest rectangle containing, the polygon. First check if
>  point is outside the outer bbox - if yes, you're done. Then check if
>  point is inside the inner bbox - if yes, you're done. Only after that do
>  the actual polygon test.)

PostGIS is thataway -->

:-)

Cheers,
Andy

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] osmxapi/bbox question

[Frederik Ramm]

Hi,

>> That way you can call the osmxapi url with [polygon=belgium] or
>> [polygon:country=belgium]
>>
>> What do the osmxapi developers think about it?
>>
> 
> It's a nice idea.  I just need to implement the algorithm described earlier
> in this thread :)

Not only do you need to implement the algorithm, you also need a 
computing environment that will be able to execute the algorithm in an 
acceptable timeframe. A halfway "correct" border polygon of a landlocked 
state easily runs into five-digit numbers of polygon nodes, and then for 
each of the 250 million nodes in the database, you have to find out 
whether it lies in that polygon.

(An obvious optimization is to compute the largest rectangle contained 
in, and the largest rectangle containing, the polygon. First check if 
point is outside the outer bbox - if yes, you're done. Then check if 
point is inside the inner bbox - if yes, you're done. Only after that do 
the actual polygon test.)

Bye
Frederik

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] osmxapi/bbox question

[80n]

On Fri, Apr 18, 2008 at 3:14 PM, Johan Huysmans <[EMAIL PROTECTED]>
wrote:

> That's exactly what i mean/want :D
>
> That way you can call the osmxapi url with [polygon=belgium] or
> [polygon:country=belgium]
>
> What do the osmxapi developers think about it?
>

It's a nice idea.  I just need to implement the algorithm described earlier
in this thread :)

80n


>
> Greetings Johan
>
> Rob wrote:
> > i would be cool if the osmxapi could accept a href to a polygon xml
> > file reference instead of a bbox. We can put a list of
> > country/province/city/... polygons somewhere on a site
> >
> > 2008/4/18, Johan Huysmans <[EMAIL PROTECTED]>:
> >
> >> And a combination of both? Does that exists.
> >>
> >>  Now my php script just eats all memory when parsing the osm file :(
> >>
> >>
> >>  Johan
> >>
> >>
> >>  Skywave wrote:
> >>  > Download from here, it uses a polygon instead of a bbox.
> >>  > http://download.geofabrik.de/osm/europe/
> >>  >
> >>  > On Fri, Apr 18, 2008 at 10:04 AM, Johan Huysmans
> >>  > <[EMAIL PROTECTED]> wrote:
> >>  >
> >>  >> Hi,
> >>  >>
> >>  >>  Currently i'm working with the bbox of Belgium, but this bbox
> includes
> >>  >>  parts of the Netherlands, France,..
> >>  >>
> >>  >>  And this gives me some problems... it appears that some places in
> >>  >>  Belgium also exists in the Netherlands or France.
> >>  >>
> >>  >>  Apparently it is only possible to use bbox-es to limit the size.
> >>  >>  Are there any ideas or plans to implement some way you can limit
> the
> >>  >>  size for eg. a country?
> >>  >>
> >>  >>  Johan
> >>  >>
> >>  >>
> >>  >>  80n wrote:
> >>  >>  > You can have any shaped bbox you like as long as it is a
> rectangle ;)
> >>  >>  >
> >>  >>  > Can anyone point me to a good algorithm for selecting points
> within an
> >>  >>  > arbitrary polygon?
> >>  >>  >
> >>  >>  > 80n
> >>  >>  >
> >>  >>  > On Fri, Apr 11, 2008 at 1:01 PM, Johan Huysmans
> >>  >>
> >>  >>
> >>  >>> <[EMAIL PROTECTED] >
> wrote:
> >>  >>>
> >>  >>  >
> >>  >>  > Hi All,
> >>  >>  >
> >>  >>  > I' experimenting with osmxapi to get a list of all places in
> Belgium.
> >>  >>  > Getting a list of all places is no problem, but the list is
> a bit too
> >>  >>  > large ;)
> >>  >>  >
> >>  >>  > Can I specify that I only want the places in Belgium? Can
> this be done
> >>  >>  > with bbox?
> >>  >>  >
> >>  >>  > Is there a known mapping that give you the exact bbox for
> each
> >>  >>  > country?
> >>  >>  >
> >>  >>  > Thx, Johan Huysmans
> >>  >>  >
> >>  >>  > ___
> >>  >>  > talk mailing list
> >>  >>  > talk@openstreetmap.org 
> >>  >>
> >>  >>
> >>  >>
> >>  >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
> >>  >>>
> >>  >>  >
> >>  >>  >
> >>  >>
> >>  >>  ___
> >>  >>  talk mailing list
> >>  >>  talk@openstreetmap.org
> >>  >>  http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
> >>  >>
> >>  >>
> >>  >
> >>  > ___
> >>  > talk mailing list
> >>  > talk@openstreetmap.org
> >>  > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
> >>  >
> >>
> >>  ___
> >>  talk mailing list
> >>  talk@openstreetmap.org
> >>  http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
> >>
> >>
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
> >
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] GPS accuracy

[Chris Hill]

Over last week I've noticed that the accuracy reading on my ETrex has briefly 
gone down to 10ft a few times.  Before last Saturday the best was 16ft.  Today 
I saw 9ft briefly.  Anyone else seen this or know what's going on?
 
cheers, Chris




  __
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] house numbers revisited

[Adam Schreiber]

On Fri, Apr 18, 2008 at 3:58 AM, Martijn van Oosterhout
<[EMAIL PROTECTED]> wrote:
> On Thu, Apr 17, 2008 at 3:05 PM, Jonathan Bennett
>  <[EMAIL PROTECTED]> wrote:
>  > Frederik Ramm wrote:
>  >  > A completely different (and quite OSM-like!) option is dropping all this
>  >  > complex logic, left-right-blah tagging, number schemes, relations and
>  >  > all, and just put simple nodes: "This is B street number 25". This
>  >  > brings redundancy, typos, and all - but we're used to that. It would be
>  >  > *extremely* easy to edit, and renderers or routers would have to do a
>  >  > little bit of processing to work with the data. Not too hard probably.
>  >
>  >  I think this scheme works best, because we can carry it forward to
>  >  houses being areas tagged 'building=...' -- there's an issue with
>  >  semi-detached and terraced houses to be worked out (1 way per building
>  >  vs. 1 way per residence), but that's probably some way off needing to be
>  >  solved.
>
>  The biggest problem with this is that it's essentially impossible to
>  convert existing house number data to this format. We have for NL
>  complete house number data in the form of: left/right start/end
>  scheme. Converting this to what you suggest is, well, essentially
>  impossible.
>
>  So maybe we should use both. The rest of the GIS world works fine on
>  left/right start/end scheme, I don't know why we need to do anything
>  else.

Perhaps we could take a Google Maps approach to this.  Currently they
have a method that when given a location that isn't quite right, the
user is allowed to move the point to the "correct" spot.  This sounds
a lot like what we have going for us with some tweaks to the Potlach
interface.

We could import the range data, by evenly spacing "street number"
nodes along the road in question.  Local mappers can easily move the
nodes around in JOSM and end users/consumers of the data can adjust
addresses they know in a one off fashion via Potlach.

Cheers,

Adam

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] osmxapi/bbox question

[Johan Huysmans]

That's exactly what i mean/want :D

That way you can call the osmxapi url with [polygon=belgium] or 
[polygon:country=belgium]

What do the osmxapi developers think about it?

Greetings Johan

Rob wrote:
> i would be cool if the osmxapi could accept a href to a polygon xml
> file reference instead of a bbox. We can put a list of
> country/province/city/... polygons somewhere on a site
>
> 2008/4/18, Johan Huysmans <[EMAIL PROTECTED]>:
>   
>> And a combination of both? Does that exists.
>>
>>  Now my php script just eats all memory when parsing the osm file :(
>>
>>
>>  Johan
>>
>>
>>  Skywave wrote:
>>  > Download from here, it uses a polygon instead of a bbox.
>>  > http://download.geofabrik.de/osm/europe/
>>  >
>>  > On Fri, Apr 18, 2008 at 10:04 AM, Johan Huysmans
>>  > <[EMAIL PROTECTED]> wrote:
>>  >
>>  >> Hi,
>>  >>
>>  >>  Currently i'm working with the bbox of Belgium, but this bbox includes
>>  >>  parts of the Netherlands, France,..
>>  >>
>>  >>  And this gives me some problems... it appears that some places in
>>  >>  Belgium also exists in the Netherlands or France.
>>  >>
>>  >>  Apparently it is only possible to use bbox-es to limit the size.
>>  >>  Are there any ideas or plans to implement some way you can limit the
>>  >>  size for eg. a country?
>>  >>
>>  >>  Johan
>>  >>
>>  >>
>>  >>  80n wrote:
>>  >>  > You can have any shaped bbox you like as long as it is a rectangle ;)
>>  >>  >
>>  >>  > Can anyone point me to a good algorithm for selecting points within an
>>  >>  > arbitrary polygon?
>>  >>  >
>>  >>  > 80n
>>  >>  >
>>  >>  > On Fri, Apr 11, 2008 at 1:01 PM, Johan Huysmans
>>  >>
>>  >>
>>  >>> <[EMAIL PROTECTED] > wrote:
>>  >>>
>>  >>  >
>>  >>  > Hi All,
>>  >>  >
>>  >>  > I' experimenting with osmxapi to get a list of all places in 
>> Belgium.
>>  >>  > Getting a list of all places is no problem, but the list is a bit 
>> too
>>  >>  > large ;)
>>  >>  >
>>  >>  > Can I specify that I only want the places in Belgium? Can this be 
>> done
>>  >>  > with bbox?
>>  >>  >
>>  >>  > Is there a known mapping that give you the exact bbox for each
>>  >>  > country?
>>  >>  >
>>  >>  > Thx, Johan Huysmans
>>  >>  >
>>  >>  > ___
>>  >>  > talk mailing list
>>  >>  > talk@openstreetmap.org 
>>  >>
>>  >>
>>  >>
>>  >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>>  >>>
>>  >>  >
>>  >>  >
>>  >>
>>  >>  ___
>>  >>  talk mailing list
>>  >>  talk@openstreetmap.org
>>  >>  http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>>  >>
>>  >>
>>  >
>>  > ___
>>  > talk mailing list
>>  > talk@openstreetmap.org
>>  > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>>  >
>>
>>  ___
>>  talk mailing list
>>  talk@openstreetmap.org
>>  http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>>
>> 
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>   

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Firefox quirks

[Steve Chilton]

Excellent. All sorted. Thnx

Steve Chilton, Learning Support Fellow
Learning and Technical Support Unit Manager
School of Health and Social Sciences
Middlesex University
phone/fax: 020 8411 5355
email: [EMAIL PROTECTED]
http://www.mdx.ac.uk/schools/hssc/staff/profiles/technical/chiltons.asp

Chair of the Society of Cartographers: http://www.soc.org.uk/

SoC conference 2008:
http://www.abdn.ac.uk/cartographers08/

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Hughes
Sent: 18 April 2008 14:57
To: talk@openstreetmap.org
Subject: Re: [OSM-talk] Firefox quirks

In message
<[EMAIL PROTECTED]>
Steve Chilton <[EMAIL PROTECTED]> wrote:

> Could someone please have a look at the Firefox browser with slippy
map?
> I have FF2.0.0.14 and it has two annoying things happening.
> 1 the red marquee when you shift-drag to resize has gone. Not
important
> but is nice to have confirmation of re-zoom you have just set, and a
> graphic as you drag around and decide
> 2 the scale bar info lurks top left and is under the
left/right/up/down
> arrows - which also seem not to work.

Your browser is caching an old copy of the OpenLayers stylesheet. Just
do a ctrl/shift reload and it will fix it.

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Tagging climbing routes and scrambles

[Steve Hill]

On Fri, 18 Apr 2008, Andy Allan wrote:

> Ah, I see the problem. You are taking a tag away from it's context,
> and then complaining that the tag has no context on its own. Only part
> of your argument is based around conflicts, but the rest seems to be
> context.

Yes, it's a bit of both - I think these are two separate problems with the 
flat name space.

> How do I tell that name="The Duke's Head" refers to the name of a pub?
> I don't feel the need for amenity:pub:name= and highway:primary:name=
> in order to solve this issue. Instead, I examine the context of the
> original tag, and find that it is the name of a pub.

Actually, I would prefer to see everything namespaced, such as 
amenity:pub:name or pub:name.  But clearly that isn't going to happen any 
time soon.

In my ideal world, the editors would allow the user to attach a 
hiararchical tree of tags to an object, which would do a wonderful job of 
identifying the exact context of each tag.  :)

> This is where
> people run into problems on the wiki - you can't explain the meaning
> of the tag "capacity" in its own right, but you can in the context of
> car parks, bike parking, football stadiums and ski lifts.

The wiki problem would, of course, be fixed if all tags were prefixed with 
the appropriate name space :)

> But this is still not an argument
> for namespaces, when we have other options (yes, relations) available

But relations are even more complex for people to understand and use than 
namespaces (which seems to be one of the primary arguments against 
namespaces)...

> So in summary, I think the "need" for namespaces is driven purely by
> people who want to view a tag in isolation yet still want to have
> context, when what they should do is not remove the context in the
> first place.

Part of the problem is that you need prior knowledge as to where the 
context comes from.  OSM treats all tags as equals, but in reality they 
aren't - for example, a "highway=motorway" tag immediately defines the 
context for all the other tags as being something to do with motorways. 
"amenity=pub" defines the context for all the other tags as being 
something to do with pubs.  But "name=Station Road" or "ref=M4" doesn't 
really change the context.  Without having prior knowledge about which 
tags are defining the context, and which are just providing data, it is 
sometimes quite ambiguous where the context comes from.  On the other 
hand, a clear namespace such as "highway:motorway:ref=M4" makes it 
immediately clear what the context is.  This makes it easier to do 
something like look up a tag in the wiki, to work out what it means.

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Tagging climbing routes and scrambles

[Tom Hughes]

In message <[EMAIL PROTECTED]>
Andy Allan <[EMAIL PROTECTED]> wrote:

> Ah, I see the problem. You are taking a tag away from it's context,
> and then complaining that the tag has no context on its own. Only part
> of your argument is based around conflicts, but the rest seems to be
> context.
>
> How do I tell that name="The Duke's Head" refers to the name of a pub?
> I don't feel the need for amenity:pub:name= and highway:primary:name=
> in order to solve this issue. Instead, I examine the context of the
> original tag, and find that it is the name of a pub.

Because the name tag is always the name of an object, regardless of
what that object is (the amenity=pub tells you what sort of object it
is in this case). It is clear to everybody that a name tag is going
to tell you the name of something without having to know anything else
about it.

It is not clear to anybody outside a very specific community what
a tag called "french" is likely to mean.

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Firefox quirks

[Tom Hughes]

In message <[EMAIL PROTECTED]>
Steve Chilton <[EMAIL PROTECTED]> wrote:

> Could someone please have a look at the Firefox browser with slippy map?
> I have FF2.0.0.14 and it has two annoying things happening.
> 1 the red marquee when you shift-drag to resize has gone. Not important
> but is nice to have confirmation of re-zoom you have just set, and a
> graphic as you drag around and decide
> 2 the scale bar info lurks top left and is under the left/right/up/down
> arrows - which also seem not to work.

Your browser is caching an old copy of the OpenLayers stylesheet. Just
do a ctrl/shift reload and it will fix it.

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] Firefox quirks

[Steve Chilton]

Could someone please have a look at the Firefox browser with slippy map?
I have FF2.0.0.14 and it has two annoying things happening.
1 the red marquee when you shift-drag to resize has gone. Not important
but is nice to have confirmation of re-zoom you have just set, and a
graphic as you drag around and decide
2 the scale bar info lurks top left and is under the left/right/up/down
arrows - which also seem not to work.

With IE 6.0.2900 these three things all work.

Cheers
STEVE

Steve Chilton, Learning Support Fellow
Learning and Technical Support Unit Manager
School of Health and Social Sciences
Middlesex University
phone/fax: 020 8411 5355
email: [EMAIL PROTECTED]
http://www.mdx.ac.uk/schools/hssc/staff/profiles/technical/chiltons.asp

Chair of the Society of Cartographers: http://www.soc.org.uk/

SoC conference 2008:
http://www.abdn.ac.uk/cartographers08/



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Tagging climbing routes and scrambles

[Andy Allan]

On Thu, Apr 17, 2008 at 2:52 PM, Steve Hill <[EMAIL PROTECTED]> wrote:
> On Thu, 17 Apr 2008, Andy Allan wrote:
>
>
> > And full of frigging namespaces.
> >
>
>  Yes - I consider this a Good Thing.

Then we'll need to do our best to persuade each other :-) !
>
> > british_trad = VS
> > british_tech = 6b
> > french = 6a
> >
> > Does the trick, nice and simple, no problems.
> >
>
>  But makes it less obvious to people who don't have a good knowledge of
> climbing as to what the tags mean.  If you have "climbing:grade:french" it
> is obvious to *everyone* that this is some kind of grade for climbing - a
> tag called "french" really does fall into the non-obvious category.

Ah, I see the problem. You are taking a tag away from it's context,
and then complaining that the tag has no context on its own. Only part
of your argument is based around conflicts, but the rest seems to be
context.

How do I tell that name="The Duke's Head" refers to the name of a pub?
I don't feel the need for amenity:pub:name= and highway:primary:name=
in order to solve this issue. Instead, I examine the context of the
original tag, and find that it is the name of a pub.

french = 6a is meaningless on its own, I agree. But there is no reason
to consider tags out of context. We don't need to for refs, or
capacity, or difficulty, or grade, or anything else. This is where
people run into problems on the wiki - you can't explain the meaning
of the tag "capacity" in its own right, but you can in the context of
car parks, bike parking, football stadiums and ski lifts.

As for conflicts, every example I have seen is actually about
conflicts of context, not conflicts of tags. So in a separate email
you refer to timetables needing namespaced - I disagree. In this case
it is not a word with two meanings that need to be separated; rather,
it is that the context of the two timetables (one for postboxes, one
for bus-stops) need to be separated. But this is still not an argument
for namespaces, when we have other options (yes, relations) available
- even for this most contrived of examples.

So in summary, I think the "need" for namespaces is driven purely by
people who want to view a tag in isolation yet still want to have
context, when what they should do is not remove the context in the
first place.

Cheers,
Andy

osm:way:outdoor:environments:piste:lift:type:seated:capacity:hourly:2500
osm:node:outdoor:sport:climbing:ropedclimbing:crag:grade:english:trad:6a

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] osmxapi/bbox question

[Rob]

i would be cool if the osmxapi could accept a href to a polygon xml
file reference instead of a bbox. We can put a list of
country/province/city/... polygons somewhere on a site

2008/4/18, Johan Huysmans <[EMAIL PROTECTED]>:
> And a combination of both? Does that exists.
>
>  Now my php script just eats all memory when parsing the osm file :(
>
>
>  Johan
>
>
>  Skywave wrote:
>  > Download from here, it uses a polygon instead of a bbox.
>  > http://download.geofabrik.de/osm/europe/
>  >
>  > On Fri, Apr 18, 2008 at 10:04 AM, Johan Huysmans
>  > <[EMAIL PROTECTED]> wrote:
>  >
>  >> Hi,
>  >>
>  >>  Currently i'm working with the bbox of Belgium, but this bbox includes
>  >>  parts of the Netherlands, France,..
>  >>
>  >>  And this gives me some problems... it appears that some places in
>  >>  Belgium also exists in the Netherlands or France.
>  >>
>  >>  Apparently it is only possible to use bbox-es to limit the size.
>  >>  Are there any ideas or plans to implement some way you can limit the
>  >>  size for eg. a country?
>  >>
>  >>  Johan
>  >>
>  >>
>  >>  80n wrote:
>  >>  > You can have any shaped bbox you like as long as it is a rectangle ;)
>  >>  >
>  >>  > Can anyone point me to a good algorithm for selecting points within an
>  >>  > arbitrary polygon?
>  >>  >
>  >>  > 80n
>  >>  >
>  >>  > On Fri, Apr 11, 2008 at 1:01 PM, Johan Huysmans
>  >>
>  >>
>  >>> <[EMAIL PROTECTED] > wrote:
>  >>>
>  >>  >
>  >>  > Hi All,
>  >>  >
>  >>  > I' experimenting with osmxapi to get a list of all places in 
> Belgium.
>  >>  > Getting a list of all places is no problem, but the list is a bit 
> too
>  >>  > large ;)
>  >>  >
>  >>  > Can I specify that I only want the places in Belgium? Can this be 
> done
>  >>  > with bbox?
>  >>  >
>  >>  > Is there a known mapping that give you the exact bbox for each
>  >>  > country?
>  >>  >
>  >>  > Thx, Johan Huysmans
>  >>  >
>  >>  > ___
>  >>  > talk mailing list
>  >>  > talk@openstreetmap.org 
>  >>
>  >>
>  >>
>  >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>  >>>
>  >>  >
>  >>  >
>  >>
>  >>  ___
>  >>  talk mailing list
>  >>  talk@openstreetmap.org
>  >>  http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>  >>
>  >>
>  >
>  > ___
>  > talk mailing list
>  > talk@openstreetmap.org
>  > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>  >
>
>  ___
>  talk mailing list
>  talk@openstreetmap.org
>  http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Tagging climbing routes and scrambles

[Steve Hill]

On Fri, 18 Apr 2008, Robin Paulson wrote:

> structure=pole
> highway=bus_stop
> amenity=post_box

Ok, but you still have a potential conflict here.  Hypothetically, you 
could have a "timetable" tag which applies to both a bus stop (tells you 
when busses arrive) and a post box (when is the post collected?).  A neat 
solution is to have "bus_stop:timetable" and "post_box:timetable".

> a lot of the disputes over tagging are caused by people confusing
> physical items with conceptual ones; if we thought about separating
> them before debating a tagging scheme, things would be a lot clearer

That may be, but I still think in some cases you are going to want 
multiple conceptual items attached to a single item - namespacing allows 
this to be done without risk of conflicting tags and makes it more obvious 
how the tags interact with each item (conceptual or physical).

The same thing _could_ be done with relations (i.e. you mark up the 
physical items with ways and nodes and use relations containing physical 
items to represent the conceptial things).  But at the moment that would 
be even more complex than a clear set of namespaces.

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] house numbers revisited

[Frederik Ramm]

Hi,

>>> * what if way direction is reversed?
>>> * what if way is extended, merged, split?
>>
>>  That will be a problem indeed. Could theoretically be solved with
>>  strong editor support, but that does not fix the intrinsic flaw. You
>>  never know when a script comes around that reverses direction for  
>> some
>>  valid reason, outside the editors. Someone on talk-nl suggested  
>> using
>>  a NSEW-based tagging scheme, but this is not unambiguous either.
>
> I say these problems are irrelevent right now. We have other tags
> (like oneway) which break when roads are reversed and that doesn't
> seem to excite anyone enough to fix it. I'd say ignore that problem,
> when it gets solved for other tags, it'll get solved for these also.

The oneway tag dos not suffer from splitting a way. Oneway is  
displayed on the maps and sometimes in the editors as well so people  
will notice when they make mistakes. We'd have to work on giving  
house numbering the same prominence on map as oneway arrows if we  
want to enable people to spot bugs the same way they do with oneways.

In another post you say that other GIS systems have no trouble using  
a left/right start/end scheme. One has to be careful when making  
these comparisons because many many GIS systems out there are  
basically read-only, or at least not at all intended for an  
environment like ours where changes are made on a massive scale by a  
massive amount of non-expert users. Something that works well for  
them does not necessarily work well for us. It might, but it doesn't  
follow logically.

Bye
Frederik

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




___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] osm2pgsql - invalid input syntax for integer : "Breërivier"

[Ricardo Peironcely]

Yes, downloading the last version fron SVN the error was resolved.

Thanks.
Rpr


2008/4/16, Martijn van Oosterhout <[EMAIL PROTECTED]>:
>
> On Wed, Apr 16, 2008 at 7:05 PM, Ricardo Peironcely
> <[EMAIL PROTECTED]> wrote:
> >
> > I've a problem with osm2pgsql and the last version of planet file.
> >
> > When I try to execute the process, always receive the same error:
> invalid
> > input syntax for integer: "Breërivier"
> >
> > Any one knows something about this?
>
> Do you have the latest version of osm2pgsql? I beleive this was fixed
> a few days ago...
>
> Have a nice day,
> --
> Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Tagging climbing routes and scrambles

[Steve Hill]

On Thu, 17 Apr 2008, Nick wrote:

> It's very difficult to know what to do with climbing routes without
> truly 3-dimensional mapping - that said your suggestion sounds feasible.

Having thought more about this, my proposal has a problem: There is no way 
to show the difference between a path leading to the bottom of a route and 
the path leading to the top of the route.  I'm starting to think that for 
routes which do have a path to the top we need to have a node for both the 
top and bottom with a way between them, even though a lot of the time 
these nodes will be practically on top of each other...

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Tagging climbing routes and scrambles

[Robin Paulson]

2008/4/18 Steve Hill <[EMAIL PROTECTED]>:
> > I simply don't see namespaces as necessary.  In this case I'd draw the
>  > building and label it as a supermarket, then add a node for the post 
> office.
>
>  This seems a very messy solution to me.
>
>
>  > The building is a supermarket, the post office is only part of it.
>
>  That may not be the case - I know of several buildings which have several
>  different shops in their own right within them, which should all have
>  equal status.  The post office may *not* just be part of the supermarket -
>  it may be a completely separate thing within the building.

actually, it's neither.

the building is a building, that's it, regardless of what is inside it
it may well contain a supermarket, and/or a post office, but the two
are different
the building is a physical item, with physical properties (length,
width, height)
the supermarket and post office are conceptual items, with no physical
properties, but abstract properties instead (operator, opening hours,
produce lines)
so, we create a building as a polygon, and label it 'building=yes' or
'building=warehouse' (modern supermarkets are usually very like
warehouses in appearance)
then we put two nodes inside it, one 'shop=supermarket' and one
'amenity=post_office'

>
>  Other examples include things like: buildings which have both toilets and
>  showers within them, bus stops and post boxes that share the same pole,

building=yes (area)
amenity=toilets (point)
amenity=showers (point) (both within building perimeter)

structure=pole
highway=bus_stop
amenity=post_box

a lot of the disputes over tagging are caused by people confusing
physical items with conceptual ones; if we thought about separating
them before debating a tagging scheme, things would be a lot clearer

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] osmxapi/bbox question

[Johan Huysmans]

And a combination of both? Does that exists.

Now my php script just eats all memory when parsing the osm file :(

Johan

Skywave wrote:
> Download from here, it uses a polygon instead of a bbox.
> http://download.geofabrik.de/osm/europe/
>
> On Fri, Apr 18, 2008 at 10:04 AM, Johan Huysmans
> <[EMAIL PROTECTED]> wrote:
>   
>> Hi,
>>
>>  Currently i'm working with the bbox of Belgium, but this bbox includes
>>  parts of the Netherlands, France,..
>>
>>  And this gives me some problems... it appears that some places in
>>  Belgium also exists in the Netherlands or France.
>>
>>  Apparently it is only possible to use bbox-es to limit the size.
>>  Are there any ideas or plans to implement some way you can limit the
>>  size for eg. a country?
>>
>>  Johan
>>
>>
>>  80n wrote:
>>  > You can have any shaped bbox you like as long as it is a rectangle ;)
>>  >
>>  > Can anyone point me to a good algorithm for selecting points within an
>>  > arbitrary polygon?
>>  >
>>  > 80n
>>  >
>>  > On Fri, Apr 11, 2008 at 1:01 PM, Johan Huysmans
>>
>> 
>>> <[EMAIL PROTECTED] > wrote:
>>>   
>>  >
>>  > Hi All,
>>  >
>>  > I' experimenting with osmxapi to get a list of all places in Belgium.
>>  > Getting a list of all places is no problem, but the list is a bit too
>>  > large ;)
>>  >
>>  > Can I specify that I only want the places in Belgium? Can this be done
>>  > with bbox?
>>  >
>>  > Is there a known mapping that give you the exact bbox for each
>>  > country?
>>  >
>>  > Thx, Johan Huysmans
>>  >
>>  > ___
>>  > talk mailing list
>>  > talk@openstreetmap.org 
>>
>>
>> 
>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>>>   
>>  >
>>  >
>>
>>  ___
>>  talk mailing list
>>  talk@openstreetmap.org
>>  http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>>
>> 
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>   

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] house numbers revisited

[Martijn van Oosterhout]

On Thu, Apr 17, 2008 at 2:36 PM, Martijn van Exel <[EMAIL PROTECTED]> wrote:
>  > Pitfalls include:
>  >
>  > * what if way direction is reversed?
>  > * what if way is extended, merged, split?
>
>  That will be a problem indeed. Could theoretically be solved with
>  strong editor support, but that does not fix the intrinsic flaw. You
>  never know when a script comes around that reverses direction for some
>  valid reason, outside the editors. Someone on talk-nl suggested using
>  a NSEW-based tagging scheme, but this is not unambiguous either.

I say these problems are irrelevent right now. We have other tags
(like oneway) which break when roads are reversed and that doesn't
seem to excite anyone enough to fix it. I'd say ignore that problem,
when it gets solved for other tags, it'll get solved for these also.

Have a nice day,
-- 
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] osmxapi/bbox question

[Skywave]

Download from here, it uses a polygon instead of a bbox.
http://download.geofabrik.de/osm/europe/

On Fri, Apr 18, 2008 at 10:04 AM, Johan Huysmans
<[EMAIL PROTECTED]> wrote:
> Hi,
>
>  Currently i'm working with the bbox of Belgium, but this bbox includes
>  parts of the Netherlands, France,..
>
>  And this gives me some problems... it appears that some places in
>  Belgium also exists in the Netherlands or France.
>
>  Apparently it is only possible to use bbox-es to limit the size.
>  Are there any ideas or plans to implement some way you can limit the
>  size for eg. a country?
>
>  Johan
>
>
>  80n wrote:
>  > You can have any shaped bbox you like as long as it is a rectangle ;)
>  >
>  > Can anyone point me to a good algorithm for selecting points within an
>  > arbitrary polygon?
>  >
>  > 80n
>  >
>  > On Fri, Apr 11, 2008 at 1:01 PM, Johan Huysmans
>
> > <[EMAIL PROTECTED] > wrote:
>  >
>  > Hi All,
>  >
>  > I' experimenting with osmxapi to get a list of all places in Belgium.
>  > Getting a list of all places is no problem, but the list is a bit too
>  > large ;)
>  >
>  > Can I specify that I only want the places in Belgium? Can this be done
>  > with bbox?
>  >
>  > Is there a known mapping that give you the exact bbox for each
>  > country?
>  >
>  > Thx, Johan Huysmans
>  >
>  > ___
>  > talk mailing list
>  > talk@openstreetmap.org 
>
>
> > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>  >
>  >
>
>  ___
>  talk mailing list
>  talk@openstreetmap.org
>  http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] osmxapi/bbox question

[Johan Huysmans]

Hi,

Currently i'm working with the bbox of Belgium, but this bbox includes 
parts of the Netherlands, France,..

And this gives me some problems... it appears that some places in 
Belgium also exists in the Netherlands or France.

Apparently it is only possible to use bbox-es to limit the size.
Are there any ideas or plans to implement some way you can limit the 
size for eg. a country?

Johan

80n wrote:
> You can have any shaped bbox you like as long as it is a rectangle ;)
>
> Can anyone point me to a good algorithm for selecting points within an 
> arbitrary polygon?
>
> 80n
>
> On Fri, Apr 11, 2008 at 1:01 PM, Johan Huysmans 
> <[EMAIL PROTECTED] > wrote:
>
> Hi All,
>
> I' experimenting with osmxapi to get a list of all places in Belgium.
> Getting a list of all places is no problem, but the list is a bit too
> large ;)
>
> Can I specify that I only want the places in Belgium? Can this be done
> with bbox?
>
> Is there a known mapping that give you the exact bbox for each
> country?
>
> Thx, Johan Huysmans
>
> ___
> talk mailing list
> talk@openstreetmap.org 
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>
>

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] house numbers revisited

[Martijn van Oosterhout]

On Thu, Apr 17, 2008 at 3:05 PM, Jonathan Bennett
<[EMAIL PROTECTED]> wrote:
> Frederik Ramm wrote:
>  > A completely different (and quite OSM-like!) option is dropping all this
>  > complex logic, left-right-blah tagging, number schemes, relations and
>  > all, and just put simple nodes: "This is B street number 25". This
>  > brings redundancy, typos, and all - but we're used to that. It would be
>  > *extremely* easy to edit, and renderers or routers would have to do a
>  > little bit of processing to work with the data. Not too hard probably.
>
>  I think this scheme works best, because we can carry it forward to
>  houses being areas tagged 'building=...' -- there's an issue with
>  semi-detached and terraced houses to be worked out (1 way per building
>  vs. 1 way per residence), but that's probably some way off needing to be
>  solved.

The biggest problem with this is that it's essentially impossible to
convert existing house number data to this format. We have for NL
complete house number data in the form of: left/right start/end
scheme. Converting this to what you suggest is, well, essentially
impossible.

So maybe we should use both. The rest of the GIS world works fine on
left/right start/end scheme, I don't know why we need to do anything
else.

Have a nice day,
-- 
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Tagging climbing routes and scrambles

[Steve Hill]

On Thu, 17 Apr 2008, Chris Hill wrote:

> I simply don't see namespaces as necessary.  In this case I'd draw the 
> building and label it as a supermarket, then add a node for the post office.

This seems a very messy solution to me.

> The building is a supermarket, the post office is only part of it.

That may not be the case - I know of several buildings which have several 
different shops in their own right within them, which should all have 
equal status.  The post office may *not* just be part of the supermarket - 
it may be a completely separate thing within the building.

Other examples include things like: buildings which have both toilets and 
showers within them, bus stops and post boxes that share the same pole, 
etc.

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk