Re: [OSM-talk] Screencasts

[Tom Higgy]

SteveC wrote:
> I've done two screencast intros to OSM, one general and one potlatch.
> 
> http://showmedo.com/videos/series?name=mS2P1ZqS6

Awsome, thanks!

I've been using JOSM so far (was no Potlatch when I'm joined and JOSM 
kind of stuck) but have been starting to use Potlatch for really minor 
edits (changing tags, etc). Having seen the video I may well use it a 
bit more now.

-- 
Cheers,

Tom
- www.tracktwo.com

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

Re: [OSM-talk] Screencasts

[Gregory]

On 19/02/2008, Andy Robinson <[EMAIL PROTECTED]> wrote:
>
> On 19/02/2008, SteveC <[EMAIL PROTECTED]> wrote:
> > I've done two screencast intros to OSM, one general and one potlatch.
> >
> > http://showmedo.com/videos/series?name=mS2P1ZqS6
> >
> > I'll add some more if there is a positive response. I'm guessing
> > they'll be useful to newbies.
> >
> > have fun,
> >
> > SteveC | [EMAIL PROTECTED] | http://www.asklater.com/steve/
> >
>
> :)
>
> Cheers
> Andy
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>

Today in one of my lessons I got into yet another conversation about OSM,
this time going a bit further than the person refusing to care because their
bog hole wasn't mapped.
Where they used to live was fairly well mapped except some road names
missing. ...Launch into an on the fly demo of OSM in action: if you complain
somethings missing I'll show you that OSM has the advantage I can add it. Me
using Potlatch (josm/laptop left at my room) to do this was like Steve in
that video. Wish I could of show the video then, would of topped off the fun
we had.

-- 
Gregory
[EMAIL PROTECTED]
http://www.livingwithdragons.com
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Screencasts

[Andy Robinson]

On 19/02/2008, SteveC <[EMAIL PROTECTED]> wrote:
> I've done two screencast intros to OSM, one general and one potlatch.
>
> http://showmedo.com/videos/series?name=mS2P1ZqS6
>
> I'll add some more if there is a positive response. I'm guessing
> they'll be useful to newbies.
>
> have fun,
>
> SteveC | [EMAIL PROTECTED] | http://www.asklater.com/steve/
>

:)

Cheers
Andy

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

Re: [OSM-talk] OSM flyer

[Alex S.]

Frederik Ramm wrote:
> I don't really know where (in an ideal world) Scribus would fit in the
> toolchain. Would you write your text with OO and make your bitmaps
> with the Gimp and vector graphics with Inkscape and then use Scribus
> to put it all together?

That's about right.


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

[OSM-talk] Screencasts

[SteveC]

I've done two screencast intros to OSM, one general and one potlatch.

http://showmedo.com/videos/series?name=mS2P1ZqS6

I'll add some more if there is a positive response. I'm guessing  
they'll be useful to newbies.

have fun,

SteveC | [EMAIL PROTECTED] | http://www.asklater.com/steve/



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

Re: [OSM-talk] OSM flyer

[Frederik Ramm]

Hi,

> > Yeah, it's not there yet. The often-suggested way ist to load the
> > finished SVG file into Scribus which does CMYK properly.
> 
> wasn't scribus an excellent candidate to design the flyer completely
> anyway?

Last time I looked at it it balked on a complex SVG created with
Inkscape; I think it complained about transparencies which I use a
lot. (I once tried to process Osmarender output with it and it didn't
work either.) Also I'm unsure how I would have to treat embedded
bitmaps (do I have to set a colour profile for them in the Gimp before
importing?).

I don't really know where (in an ideal world) Scribus would fit in the
toolchain. Would you write your text with OO and make your bitmaps
with the Gimp and vector graphics with Inkscape and then use Scribus
to put it all together?

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] updated RFC: Highway administrative and physical descriptions

[Karl Newman]

On Feb 19, 2008 3:16 PM, Alex S. <[EMAIL PROTECTED]> wrote:

> Lester Caine wrote:
> > I don't think it applies so much elsewhere - but UK motorways have no
> > pedestrian access - does the same apply on any American routes?
>
> US freeways (interstate, etc) do not allow foot traffic, in general.
> Outside of cities, however, cycles are allowed (inside of cities there's
> an alternate route ;) ).
>

Some US national (non-interstate) and state highways don't allow foot or
bicycle traffic, either, but there's always an alternate route.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] [tagging] updated RFC: Highway administrative and physical descriptions

[Alex S.]

Lester Caine wrote:
> I don't think it applies so much elsewhere - but UK motorways have no 
> pedestrian access - does the same apply on any American routes?

US freeways (interstate, etc) do not allow foot traffic, in general. 
Outside of cities, however, cycles are allowed (inside of cities there's 
an alternate route ;) ).


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

Re: [OSM-legal-talk] Deconstructing the "loss of data" claim

[Andy Robinson]

On 19/02/2008, Frederik Ramm <[EMAIL PROTECTED]> wrote:
> Hi,
>
>I am unhappy about the much-iterated claim that we would lose a lot
> of data if we were to go PD (or CC0, or a similar non-virulent
> license).
>
> Quite honestly, I think this claim is bordering on what you call
> "FUD" - fear, uncertainty, and disinformation.
>

It is possible that there has been more written about data loss on
license change than any other aspect, but that doesn't mean its being
used as the argument for one license over another.

The issue was quite simple. We need to have a license that better
protects the OSM data and clarifies how the data can be used so that
the project can effectively deliver what it set out to deliver. The
current proposal was and is considered to be the closest to the
existing license while giving these needed improvements so it was the
logical choice.

OSM never started out as a PD project so why would we think that it
would be better to recommend it go PD now? Perhaps there is room for a
mechanism that puts data into the PD if contributers wish to make
their data PD but I don't see why we would want to reinvent the
present OSM project as PD.

Cheers

Andy
-- 
Andy Robinson

___
legal-talk mailing list
[EMAIL PROTECTED]
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/legal-talk

Re: [OSM-talk] Slippymap Hosting Recommendations

[Dirk-Lüder Kreie]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Frederik Ramm schrieb:
> mkdir my-new-dir
> mount -o loop ./my-large-file my-new-dir  (needs root privs)
> 
> There you are, a new file system under my-new-dir. And if you specify  
> "-T news" when making your ext3 filesystem (or use a Reiser fs right  
> away), you have more than enough capacity for little files.

Sidenote: never put a reiserfs-image on a reiserfs partition. should you
need to --rebuild-tree your image contents will get sucked (uncleanly)
into the host reiserfs.

for a cheap provider you'll need some other method of accessing the
tiles, though. (or write a userspace-fs-driver that can run from
$WEBSERVER as cgi or similar)

- --

Dirk-Lüder "Deelkar" Kreie
Bremen - 53.0952°N 8.8652°E

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHu13FFUbODdpRVDwRAre8AKCqiiRYHW6wQ0mp7En5VIN76PGiIQCg1WcC
wJfcOXenmcK1f8qjmWW21Qg=
=N8XR
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] OSM flyer

[Christoph Eckert]

Hi,

> Yeah, it's not there yet. The often-suggested way ist to load the
> finished SVG file into Scribus which does CMYK properly.

wasn't scribus an excellent candidate to design the flyer completely anyway?

Best regards,

ce


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

Re: [OSM-talk] displayed width of roads

[Colin Marquardt]

"Dave Stubbs" <[EMAIL PROTECTED]> writes:

> On Feb 18, 2008 11:21 PM, Frederik Ramm <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> > > By co-incidence, I was in contact with another mapper who's been doing
>> > > something like this to make low zoom osmarender rendering a bit
>> > > prettier. What's everybody's opinion of this kind of practice? Is it
>> > > not an example of compromising the data (which we want to endure) to
>> > > work around a temporary deficiency in one particular renderer?
>> >
>> > If the slip roads are not really underneath the other roads then
>> > yes it is definitely wrong (IMHO). The layer tag is meant to describe
>> > the physical ordering of the roads on the ground.
>>
>> I've had a similar situation on the talk-de list where some people
>> seem to have started adding layer=1 to tram tracks. I don't like this
>> all that much (a bridge leading over a road with tram tracks would
>> then need to be layer=2 etc) but it's hard to argue with them since
>> the tram tracks *are* on top of the road. The layer tag doesn't say by
>> how much...
>
> People take things written down too seriously, I'd argue that if a
> human being can step over it it doesn't count (at a bare minimum).
> I'm sure they think this too but just want tram tracks to appear above
> roads, which is probably a sensible idea, but this isn't the way to go
> about it.

We had discussed this on IRC, and while jburgess and steve8 say it's
possible to modify osm2pgsql/Mapnik to always draw railways on top of
highways (unless the layer tag says otherwise), people had objections
because then some railways close to, but not *in* highways, might
obstruct the highways (and possibly the name), and the highways were
seen as more important.

jburgess says it might be possible to separate out trams and light_rails
from all the other railway tags and only raise these in z-order, but who
knows if this is enough... Another suggestion (from Sfan00) was having
another tag for such "in street" railways.

Cheers
  Colin


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

Re: [OSM-talk] OSM flyer

[Colin Marquardt]

Frederik Ramm <[EMAIL PROTECTED]> writes:

> PS: I like Inkscape a lot, but whenever I do stuff for printing I run
> into those nasty CMYK problems. Inkscape creates RGB PDFs, printers
> want CMYK PDFs. You can auto-convert them but without a calibrated
> screen or printer you never know how it's going to look like in print.
> I guess this can only be solved by expensive equipment - I ended up
> paying 50 Euros extra for a print designer to make me a proof on his
> inkjet printer...

Yeah, it's not there yet. The often-suggested way ist to load the
finished SVG file into Scribus which does CMYK properly.

Cheers
  Colin


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

Re: [OSM-talk] [tagging] RFC - skyhook

[J.D. Schmidt]

Stephen Gower skrev:
>   I don't think there was a formal announcement here when the
>   proposal http://wiki.openstreetmap.org/index.php/Proposed_features/Skyhook
>   was made.  Please comment on this proposal which will be opened for
>   voting two weeks from now, if appropriate.
>   
>   Best wishes
>   

I'm for it, if we at the same time can implement that OSM gets a rename 
so the new acronym becomes ASiMov (please note the capitalization used, 
in order to avoid any copyright infringement from the heirs of Isac..).

Dutch


P.S. Yeah, I know, Asimov wrote the 3 laws of robotics, while it was 
Arthur C. Clarke that wrote about space elevators (The Fountains of 
Paradise, a good read btw.). But his name doesn't make such a good 
acronym ;)

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

Re: [OSM-talk] Rendering Quarries

[Lukasz Stelmach]

Erik Johansson wrote:

On Feb 18, 2008 7:39 PM, Karl Eichwalder <[EMAIL PROTECTED]> wrote:

landuse=quarry

   |-   -|
   |-   -|
   |-   -|
   |-   -|
   |-   -|


I would like those "saw tooth" lines to signify a steep cliff as well,
would be nice to be able to paint cliffs on walking maps.


+1

--
Było mi bardzo miło.   Czwarta pospolita klęska, [...]
>Łukasz< Już nie katolicka lecz złodziejska.  (c)PP


--
Potega i sila na wyciagniecie reki - sprawdz!
Zagraj >>> http://link.interia.pl/f1cf3
begin:vcard
fn;quoted-printable:=C5=81ukasz Stelmach
n;quoted-printable:Stelmach;=C5=81ukasz
email;internet:[EMAIL PROTECTED]
x-mozilla-html:FALSE
version:2.1
end:vcard

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

Re: [OSM-talk] [tagging] updated RFC: Highway administrative and physical descriptions

[Lukasz Stelmach]

Andy Robinson (blackadder) wrote:


It's a whole lot easier to add additional tags that are logical and describe
the physical properties of the highway specifically. For the physical you
might have:

1. The number of lanes -- (lanes=)
2. The lane width (standardised in most countries). Or a measurement if not
standard. -- (lane_width=)
3. The surface construction (asphalt, concrete, dirt etc) -- (construction=)


+1

multidimensional description of a multidimensional space


--
Było mi bardzo miło.   Czwarta pospolita klęska, [...]
>Łukasz< Już nie katolicka lecz złodziejska.  (c)PP



--  
Sprawdz gdzie lezy snieg, czy dzialaja armatki
i jak przygotowane sa stoki >>> http://link.interia.pl/f1cfc

begin:vcard
fn;quoted-printable:=C5=81ukasz Stelmach
n;quoted-printable:Stelmach;=C5=81ukasz
email;internet:[EMAIL PROTECTED]
x-mozilla-html:FALSE
version:2.1
end:vcard

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

Re: [OSM-talk] [tagging] updated RFC: Highway administrative and physical descriptions

[Lukasz Stelmach]

Alex Mauer wrote:


And a polish commenter says "There are four categories:

 * state, classes A, S, GP and sometimes G
 * voivodship, classes G, Z, sometimes GP
 * powiat (county), classes G, Z, sometimes L
 * gmina (commune), classes L, D, sometimes Z"

Again, it fits very well (national/regional/county/local)


Because it was me who wrote it I just add that yet another level for 
highways might be useful. I would actually call it local, now I tag 
the unclassified. Not so long ago they have been named 
living_streets[1]. They are often maintained no by the commune 
(gmina) (or any higher administration unit) but by the owner of the 
housing district.


[1]http://wiki.openstreetmap.org/index.php/Tag:highway%3Dliving_street

--
Było mi bardzo miło.   Czwarta pospolita klęska, [...]
>Łukasz< Już nie katolicka lecz złodziejska.  (c)PP


--
Masz ostatnia szanse !
Sprawdz >>> http://link.interia.pl/f1d02  
begin:vcard
fn;quoted-printable:=C5=81ukasz Stelmach
n;quoted-printable:Stelmach;=C5=81ukasz
email;internet:[EMAIL PROTECTED]
x-mozilla-html:FALSE
version:2.1
end:vcard

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

Re: [OSM-talk] OSM flyer

[Frederik Ramm]

Hi,

> impressive job! if you could provide me an english translation, I'd be
> glad to do an italian version (maybe with updated images from an italian
> city).

I have checked in a file named TRANSLATION which contains an English
version of the texts.

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] updated RFC: Highway administrative and physical descriptions

[Alex Mauer]

Lester Caine wrote:
>> Hmm, that's not what I was going for.  I was going for the 
>> "administrative designation" of the road (that is, M, A, B [I gather] in 
>> the UK, I-, US, [state abbrev] in the US) .  In the US this is closely 
>> tied to who maintains it.  In Europe it seems to be much more closely 
>> tied to its physical characteristics, and varies wildly from country to 
>> country.
> 
> The basic problem is the lack of any clarity between countries on road 
> definitions. The 'designation' of a road adds little to knowledge of its 
> structure in the UK some main A roads have single lane passing places and 10 
> MPH speed limits while others are much higher quality than most motorways. 
> Just keep the road designation as it reference number and then worry about 
> such things as 3 4 or 5 lanes each way without reference to 'different types 
> of motorway'.

But is there any easy/consistent way to determine whether a road is a
"national route", "regional route", "county route" or something similar
to that, in the UK?

based upon
http://en.wikipedia.org/wiki/Great_Britain_road_numbering_scheme it
seems to me that A roads correspond with a national route, and B with a
regional route.

 From comments on the proposal, germany's "Bundesstrasse", 
"Staatsstrasse", "Kreisstrasse" (machine translation: "Federal street", 
"state street" and "circle street") -- at least the first two correspond 
very nicely, and the concept matches nicely overall.

And a polish commenter says "There are four categories:

 * state, classes A, S, GP and sometimes G
 * voivodship, classes G, Z, sometimes GP
 * powiat (county), classes G, Z, sometimes L
 * gmina (commune), classes L, D, sometimes Z"

Again, it fits very well (national/regional/county/local)

Specific terminology for the third level isn't important, and if a level 
between region and county is found to be necessary somewhere (China?), 
that can easily be added.

> 
> I don't think it applies so much elsewhere - but UK motorways have no 
> pedestrian access - does the same apply on any American routes?
> 

Yep, same thing for interstates in the US.  I'm not sure whether it's 
the case for the "almost motorway/interstate" situation.

-Alex Mauer "hawke"


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

Re: [OSM-talk] Contours on the Cycle Map

[Christoph Eckert]

Hi,

> I don't have photos now, because I'm at work

http://de.wikipedia.org/wiki/Schutzhütte

Image two shows a typical one IMO.

Best regards,

ce


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

Re: [OSM-talk] Backup / mirror capacity needs

[Sebastian Spaeth]

Martijn van Exel wrote:

Just my personal opinion...
> First thing that springs to mind is mirror capacity for the planet  
> dumps (possibly with more retention).

> Questions:
> * Do we need extra mirror capacity for the planet dumps?

We have heanet.ie as a mirror, I guess they are pretty good and I don't 
see the need for more mirrors.

> * Do we need more retention?

I have been deleting some of the full planet dumps from 2007 where we 
have the diffs so that we can reconstruct them easily (keeping at least 
one full dump per month) because they were filling up the planet 
partition on the dev server.

> * Any other usage for online storage? Keep in mind it's just dumb  
> storage, so no DB / applications and such.

As long as we can use hypercube courtesy to crschmid, I think we are 
pretty well off, but as soon as that changes we would need something else.

Sebastian

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

Re: [OSM-talk] Contours on the Cycle Map

[Keith Sharp]

On Tue, 2008-02-19 at 09:34 +, Andy Allan wrote:
> On Feb 18, 2008 4:46 PM, Keith Sharp <[EMAIL PROTECTED]> wrote:
> 
> > This is great!  Any chance of a write up on how you did this?
> 
> It involves a GPS, two bits of string, a barometer and a long weekend
> walking in circles around every hillside in the country...
> 
> In reality, it's fairly easy, and is based on using SRTM data and
> gdal_contour to create the shapefiles, with a few basic scripts to tie
> everything together. I'll make a page on the wiki with all the code to
> get from NASA to the rendered contours on it the next time I have an
> hour free.

Thanks Andy, I'll look out for the page appearing.

Keith.


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

Re: [OSM-talk] [tagging] updated RFC: Highway administrative and physical descriptions

[Lester Caine]

Alex Mauer wrote:
> Lester Caine wrote:
>> Alex Mauer wrote:
>>> I've added a decision tree to the physical section of the page, as well 
>>> as removed the "boulevard" designation (since it didn't really add much)
>>>
>>> I'd like to have some more comments from the UK and german end, as to 
>>> whether or not A and B roads (and others?) fit into the highway:admin 
>>> scheme.
>>>
>>> Again, the proposal location is:
>>> http://wiki.openstreetmap.org/index.php/Proposed_features/Highway_administrative_and_physical_descriptions
>> :admin is appropriate for the UK - but not laid out as it is at present. 
>> Motorways may be under different administration to the 'Highways Agency' and 
>> the 'Highways Agency' is also responsible for other main roads, but private 
>> companies will actually be responsible for managing those roads.
>> Basically WHO admins a road is a bit of a lottery, so trying to create a 
>> simple list as currently proposed is wrong for the UK :( :admin SHOULD be 
>> the 
>> company responsible for maintaining the road.
> 
> Hmm, that's not what I was going for.  I was going for the 
> "administrative designation" of the road (that is, M, A, B [I gather] in 
> the UK, I-, US, [state abbrev] in the US) .  In the US this is closely 
> tied to who maintains it.  In Europe it seems to be much more closely 
> tied to its physical characteristics, and varies wildly from country to 
> country.

The basic problem is the lack of any clarity between countries on road 
definitions. The 'designation' of a road adds little to knowledge of its 
structure in the UK some main A roads have single lane passing places and 10 
MPH speed limits while others are much higher quality than most motorways. 
Just keep the road designation as it reference number and then worry about 
such things as 3 4 or 5 lanes each way without reference to 'different types 
of motorway'.

I don't think it applies so much elsewhere - but UK motorways have no 
pedestrian access - does the same apply on any American routes?

-- 
Lester Caine - G8HFL
-
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird - http://www.firebirdsql.org/index.php

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

Re: [OSM-talk] [tagging] updated RFC: Highway administrative and physical descriptions

[Andy Robinson (blackadder)]

Alex Mauer wrote:
>Sent: 18 February 2008 11:16 PM
>To: talk@openstreetmap.org
>Subject: Re: [OSM-talk] [tagging] updated RFC: Highway administrative and
>physical descriptions
>
>I've added a decision tree to the physical section of the page, as well
>as removed the "boulevard" designation (since it didn't really add much)
>
>I'd like to have some more comments from the UK and german end, as to
>whether or not A and B roads (and others?) fit into the highway:admin
>scheme.
>
>Again, the proposal location is:
>http://wiki.openstreetmap.org/index.php/Proposed_features/Highway_administr
>ative_and_physical_descriptions
>


It's a whole lot easier to add additional tags that are logical and describe
the physical properties of the highway specifically. For the physical you
might have:

1. The number of lanes -- (lanes=)
2. The lane width (standardised in most countries). Or a measurement if not
standard. -- (lane_width=)
3. The surface construction (asphalt, concrete, dirt etc) -- (construction=)

You can then go further and add additional tags that define all the other
street furniture and attributes. None need to be complicated or difficult to
understand.

You can do the same for administrative designations that go beyond the
simple highway= approach we started with. These don't supersede the existing
tags, they simply add to the overall definition of the object.

The big question though is who wants to spend hours adding 20 tags to each
piece of road. Maybe when I have finished mapping my whole area I'll look at
it again and start to add more tags, but for now I just use the basics and
its good enough for now.

Cheers

Andy


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

[OSM-talk] Open Knowledge 2008, Saturday March 15th, LSE, London

[jo]

dear all,

I hope this event may be of interest to those in the OSM community
able to be in London mid-March. Presentations include MySociety's 
latest "time travel maps" project using OpenStreetmap base data (the
2006 version was using Ordnance Survey mapping). The afternoon
features a panel on "Law and Licensing" and presentation by Jordan
Hatcher on the Open Data Commons license set which OSMF is considering. 

# Open Knowledge (OKCon) 2008: LSE, London, 15th March 2008 #

* OKCon 2008 - 'Open Knowledge: Applications, Tools and Services'
* where: London School of Economics, London, UK
* when: 15th March 2008 (1030-1830)
* www: 
* register: 
* wiki: 

Following on from the success of our inaugural conference last year,
we're pleased to announce that the second Open Knowledge conference
(OKCon) will take place on Saturday 15th March 2008.

The event will bring together individuals and groups from across the
open knowledge spectrum for a day of seminars and workshops around the
theme of 'Applications, Tools and Services'. Three main sessions will
focus on 'Transport and Environment', 'Visualization and Analysis' and
'Education and Academia'. In addition there will be an 'Open Space'
suitable for presentations and demos of general open knowledge related
work.

The event is open to all but we encourage you to register because space
is limited. A small entrance fee is planned to help pay for costs but
concessions are available.

### More Information ### 

'Open Knowledge' is material that others are free to access, reuse or
re-distribute and may be anything from sonnets to statistics, genes to
geodata. In recent years we've seen the growth of successful open
knowledge projects - from peer reviewed journals to community edited
encyclopaedias - but what impact can open licensing have in education,
research and commerce? Is sharing the key to scaling? What kinds of
business models are available to open knowledge distributors and how
is open knowledge applied in different institutional and professional
contexts?

There now exists a vast amount of open content and data but what kinds
of tools are available to analyse and represent this wealth of
material?
How can we sort, search, store it to maximise its visibility and
reusability?

We've also witnessed the rise of web-based services -- from social
networking sites to online spreadsheet packages. While we have
definitions for open software and open knowledge, what is an open
service and what kinds of new services can be built using open
knowledge?
-- 

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

Re: [OSM-talk] [tagging] updated RFC: Highway administrative and physical descriptions

[Alex Mauer]

Lester Caine wrote:
> Alex Mauer wrote:
>> I've added a decision tree to the physical section of the page, as well 
>> as removed the "boulevard" designation (since it didn't really add much)
>>
>> I'd like to have some more comments from the UK and german end, as to 
>> whether or not A and B roads (and others?) fit into the highway:admin 
>> scheme.
>>
>> Again, the proposal location is:
>> http://wiki.openstreetmap.org/index.php/Proposed_features/Highway_administrative_and_physical_descriptions
> 
> :admin is appropriate for the UK - but not laid out as it is at present. 
> Motorways may be under different administration to the 'Highways Agency' and 
> the 'Highways Agency' is also responsible for other main roads, but private 
> companies will actually be responsible for managing those roads.
> Basically WHO admins a road is a bit of a lottery, so trying to create a 
> simple list as currently proposed is wrong for the UK :( :admin SHOULD be the 
> company responsible for maintaining the road.

Hmm, that's not what I was going for.  I was going for the 
"administrative designation" of the road (that is, M, A, B [I gather] in 
the UK, I-, US, [state abbrev] in the US) .  In the US this is closely 
tied to who maintains it.  In Europe it seems to be much more closely 
tied to its physical characteristics, and varies wildly from country to 
country.

> :physical simply adds complications without actually fixing anything. Trying 
> to add _almost and _twolane does not provide ANY useful information, and a UK 
> dual_carriageway is unlikely to have shoulders. Infact HAVING hard shoulders 
> is part of the definition that makes it a motorway, and may result in it 
> being 
> A...(M) - OK a motorway_almost except that the A1(M) has three lanes in areas.
> So it does not fit the decision tree and if it does not have two lanes why is 
> it a (motorway_twolane) ? it's motorway_singlelane but then it would probably 
> not be a motorway )

OK, I made some corrections; I realized that I was taking the 
designation into account in the decision of "motorway" vs. 
"motorway_almost" (because in the US that's the only way to tell/be sure)

If "physical" adds complications without fixing anything, then it itself 
needs to be modified to cover the situations that it doesn't.

What kind of physical roads are not covered by highway:physical?

Many people are saying things like "just use highway as-is", but that's 
really not tenable.  "trunk" (and even "primary", "secondary", 
"tertiary" or "A","B","C") says nothing whatever about the physical 
characteristics of the road.  And then anywhere below those 
designations, there's no description of the physical characteristics of 
the road.

> Yes I know I should put this on the talk page - but I can't get in at the 
> moment :(

Meh, mailing lists are better for discussion anyway.


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

Re: [OSM-talk] OSM flyer

[wiseLYNX]

Frederik Ramm wrote:
> Hi,
> 
>we (that's Y.T. and the folks on talk-de) have created an OSM flyer
> that we can hand out to folks who ask us what we're doing. 
[snip]
> The design has been done in Inkscape, and all the raw material and a
> README file is in SVN under
> 
> /misc/pr_material/german_flyer_2008-01/
> 
> so if anyone wants to do something similar for their area of
> interest, just re-use anything you want. I'll even translate the text
> for you if there's interest. 

impressive job! if you could provide me an english translation, I'd be
glad to do an italian version (maybe with updated images from an italian
city).

if any other italian speaking people wants to help me, it would be welcome.

thanks,

Enrico

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

Re: [OSM-talk] OSM flyer

[Jo]

Frederik Ramm wrote:
> Hi,
>
>we (that's Y.T. and the folks on talk-de) have created an OSM flyer
> that we can hand out to folks who ask us what we're doing. 
>
> The flyer is DIN A7 sized (74mm wide and 105mm high) and has 8 pages
> (8 pages sounds a lot but it's just one stripe of paper 105mm high and
> 296mm wide, zig-zag folded three times). We're trying to get the most
> important things across: Look how cool we are, and it's all free, and
> this is something else than free as in beer, and this is how we do it.
>
> We have printed 5,000 copies (it's not really expensive - 200 Euros
> for the lot, and some online printers would have done it for 150) and
> we'll try to distribute them widely within the community so that every
> mapper has a few of them with him when he's on the road.
>
> Here's how it looks like:
>
> front page - 
> http://svn.openstreetmap.org/misc/pr_material/german_flyer_2008-01/osmflyer1.png
> rear page - 
> http://svn.openstreetmap.org/misc/pr_material/german_flyer_2008-01/osmflyer2.png
>   
The flyer looks great. I might look into producing a Dutch version of 
it, if there is interest from Dutch and Belgian mappers.
> PPS: If you read the first letter of each paragraph in sequence, they
> spell out "P.o.t.l.a.t.c.h.m.u.s.t.d.i.e."
>   
That's not very nice. (I like Potlatch by the way, I use it just as much 
as JOSM. Some things are just a lot easier with it. Splitting circular 
roads for instance and tracing imagery)
> PPPS: Just kidding to get Richard's attention ;-)
>
>   
I checked and it's also not true... Would be a bit weird to have an 
English Easter egg in a German text...

Polyglot


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

Re: [OSM-talk] displayed width of roads

[Jo]

Frederik Ramm wrote:
> Hi,
>
>   
>>> By co-incidence, I was in contact with another mapper who's been doing
>>> something like this to make low zoom osmarender rendering a bit
>>> prettier. What's everybody's opinion of this kind of practice? Is it
>>> not an example of compromising the data (which we want to endure) to
>>> work around a temporary deficiency in one particular renderer?
>>>   
>> If the slip roads are not really underneath the other roads then
>> yes it is definitely wrong (IMHO). The layer tag is meant to describe
>> the physical ordering of the roads on the ground.
>> 
>
> I've had a similar situation on the talk-de list where some people
> seem to have started adding layer=1 to tram tracks. I don't like this
> all that much (a bridge leading over a road with tram tracks would
> then need to be layer=2 etc) but it's hard to argue with them since
> the tram tracks *are* on top of the road. The layer tag doesn't say by
> how much...
>   
I would argue that the tram tracks should be -1 since they are kind of 
embedded. That way you can take their 1 and add -1, giving 0 once again :-)

Just kidding.

Polyglot

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

[OSM-talk] 500 error

[Maning Sambale]

It ok now.

maning


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

[OSM-talk] 500 error

[Maning Sambale]

Hi,

Are there any server problems?  I can't seem to download my usual area.
It returns an http 500 error at 
http://www.openstreetmap.org/index.html?mlat=14.541720229896098&mlon=121.02042159290963&zoom=9

cheers,

maning


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

Re: [OSM-talk] download.geofabrik.de planet extracts out of sync

[Frederik Ramm]

Hi,

I'm currently fixing the problem using a synthesized diff that Dodi 
sent me (thanks!).

> I can work it out with JOSM, but it takes a very long time to "prepare 
> the data". Maybe I should work out a way to merge two raw osm xml 
> files...

Osmosis can do that.

Bye
Frederik

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

Re: [OSM-talk] Announcing a controllable Audio player and synchronisation with continuous sound tracks in JOSM

[David Earl]

On 19/02/2008 09:50, David Earl wrote:
> (***) I'm not sure this is doing 10 seconds at the moment - I will look 
> at this.

This was OK.

However, there _was_ a timing problem when synchronizing to a point 
other than the first one in a layer, now fixed ready for tomorrow's build

There is also a null pointer exception with 'play previous marker' when 
you were already at the first marker, ditto.

David


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

Re: [OSM-talk] download.geofabrik.de planet extracts out of sync

[Dirk-Lüder Kreie]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ben Laenen schrieb:
> On Tuesday 19 February 2008, Martijn van Oosterhout wrote:
>>> Can this be fixed please? It's by far the easiest method to
>>> download big areas at once.
>> There's osmxapi if you really need it?
> 
> osmxapi isn't an option for me, as it doesn't return the relations, and 
> that's exactly what I'm playing with :-)
> 
> I can work it out with JOSM, but it takes a very long time to "prepare 
> the data". Maybe I should work out a way to merge two raw osm xml 
> files...

There is perl code for that in the tilesAtHome project in svn.

- --

Dirk-Lüder "Deelkar" Kreie
Bremen - 53.0952°N 8.8652°E

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHuujfFUbODdpRVDwRArLEAJ0c447GSTfOz/DNQSndDaTZTlm3GgCeLjHP
nhIetLtpRerLSz4f6HbtLQk=
=Oql8
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] [tagging] RFC - skyhook

[Stephen Gower]

  I don't think there was a formal announcement here when the
  proposal http://wiki.openstreetmap.org/index.php/Proposed_features/Skyhook
  was made.  Please comment on this proposal which will be opened for
  voting two weeks from now, if appropriate.
  
  Best wishes
  
  s

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

Re: [OSM-talk] download.geofabrik.de planet extracts out of sync

[Ben Laenen]

On Tuesday 19 February 2008, Martijn van Oosterhout wrote:
> > Can this be fixed please? It's by far the easiest method to
> > download big areas at once.
>
> There's osmxapi if you really need it?

osmxapi isn't an option for me, as it doesn't return the relations, and 
that's exactly what I'm playing with :-)

I can work it out with JOSM, but it takes a very long time to "prepare 
the data". Maybe I should work out a way to merge two raw osm xml 
files...

Greetings
Ben

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

Re: [OSM-talk] download.geofabrik.de planet extracts out of sync

[Dodi]

Missing daily diff for  20080216-20080217 composed from hourly diff using 
osmosis is avialable at

http://www.freemap.sk/daily-20080216-20080217.osc.bz2  :P



Dodi

- Original Message - 
From: "Frederik Ramm" <[EMAIL PROTECTED]>
To: "Ben Laenen" <[EMAIL PROTECTED]>
Cc: 
Sent: Tuesday, February 19, 2008 2:28 PM
Subject: Re: [OSM-talk] download.geofabrik.de planet extracts out of sync


Hi,

> If the person who's in charge of the planet extracts at
> http://download.geofabrik.de/osm/europe/ is reading this: they're not
> in sync anymore with the current OSM data since yesterday (well, at
> least those of Belgium are out of sync, haven't tested the other
> ones).

Martijn's right, I can't fix it until the next planet comes out.

(I think I'm going to download the hourly diffs in the future so that
I have a fallback for cases like that.)

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


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

Re: [OSM-talk] download.geofabrik.de planet extracts out of sync

[Tom Hughes]

In message <[EMAIL PROTECTED]>
Frederik Ramm <[EMAIL PROTECTED]> wrote:

>> If the person who's in charge of the planet extracts at
>> http://download.geofabrik.de/osm/europe/ is reading this: they're not
>> in sync anymore with the current OSM data since yesterday (well, at
>> least those of Belgium are out of sync, haven't tested the other  
>> ones).
>
> Martijn's right, I can't fix it until the next planet comes out.
>
> (I think I'm going to download the hourly diffs in the future so that  
> I have a fallback for cases like that.)

I don't think it would have helped much as they were also broken ;-)

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] download.geofabrik.de planet extracts out of sync

[Frederik Ramm]

Hi,

> If the person who's in charge of the planet extracts at
> http://download.geofabrik.de/osm/europe/ is reading this: they're not
> in sync anymore with the current OSM data since yesterday (well, at
> least those of Belgium are out of sync, haven't tested the other  
> ones).

Martijn's right, I can't fix it until the next planet comes out.

(I think I'm going to download the hourly diffs in the future so that  
I have a fallback for cases like that.)

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] download.geofabrik.de planet extracts out of sync

[Martijn van Oosterhout]

On Feb 19, 2008 2:09 PM, Ben Laenen <[EMAIL PROTECTED]> wrote:
> If the person who's in charge of the planet extracts at
> http://download.geofabrik.de/osm/europe/ is reading this: they're not
> in sync anymore with the current OSM data since yesterday (well, at
> least those of Belgium are out of sync, haven't tested the other ones).

A daily diff was skipped this week, there's nothing that they can do
about that. The coastline checker has the same problem. As of tomorrow
the new weekly dump will be there and hopefully all should get back to
normal.

http://planet.openstreetmap.org/daily/

> Can this be fixed please? It's by far the easiest method to download big
> areas at once.

There's osmxapi if you really need it?

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] Slippy map - clickable POI

[Martijn van Oosterhout]

On Feb 19, 2008 1:17 PM, Gregory <[EMAIL PROTECTED]> wrote:
> So do you have the source code of
> http://dev.openstreetmap.org/~kleptog/pois/pois.php (or an equal example)
> available somewhere?

Sure:
http://dev.openstreetmap.org/~kleptog/pois/pois.php.txt
It just calls a perl script, 'cause dev can't do normal CGI scripts
http://dev.openstreetmap.org/~kleptog/pois/pois.pl
http://dev.openstreetmap.org/~kleptog/pois/mk_pois.pl

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

[OSM-talk] download.geofabrik.de planet extracts out of sync

[Ben Laenen]

If the person who's in charge of the planet extracts at 
http://download.geofabrik.de/osm/europe/ is reading this: they're not 
in sync anymore with the current OSM data since yesterday (well, at 
least those of Belgium are out of sync, haven't tested the other ones).

It looks like the data hasn't been updated one day, so all newly added 
ways and points that day are now not in the extracts (also giving 
awkward results for relations for example).

Can this be fixed please? It's by far the easiest method to download big 
areas at once.

Greetings
Ben

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

Re: [OSM-talk] Slippy map - clickable POI

[Gregory]

On 19/02/2008, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
>
> On Feb 18, 2008 9:01 PM, Gregory <[EMAIL PROTECTED]> wrote:
> > I've created an openlayers slippy map here (the tiles are via kosmos):
> >  http://www.livingwithdragons.com/maps/slippytest.php
> >
> > And if you click on any of the pub symbols, you get a pop up (well text
> > displaying at the side on the page would be nicer, but I rekon I can
> figure
> > that out).
> >  Thing is if you look at the code(line 70+) you'll see I'm manually
> entering
> > in the lat/lon box where each symbol appears. Not ideal, especially when
> the
> > POI are in the map data.
>
> You need something on the server to get the POI data on the fly as in:
> http://dev.openstreetmap.org/~kleptog/pois/pois.html
>
> Have a nice day,
> --
> Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/
>


So do you have the source code of
http://dev.openstreetmap.org/~kleptog/pois/pois.php(or an equal example)
available somewhere?

Sven: I had a look at the html, but I'm much more familiar with php so
probably likely to go further.

-- 
Gregory
[EMAIL PROTECTED]
http://www.livingwithdragons.com
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] displayed width of roads

[Martijn van Oosterhout]

On Feb 19, 2008 10:39 AM, Andy Allan <[EMAIL PROTECTED]> wrote:
> You could politely encourage everyone to figure out where the bug in
> the rendering is, and either file trac ticket or submit a patch. The
> more details, examples, clarity of explanation and so on the better.

Indeed, we have been given no details of the problem (which renderer
for example), where? If people don't report these problems they'll
never get fixed.

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] place=country/nation/state

[Abigail Brady]

On Feb 19, 2008 1:03 AM, Iván Sánchez Ortega <[EMAIL PROTECTED]>
wrote:

> For example: here in Spain, the NUTS1 level is an artificial
> classification.
> Nobody in spain would use that.
>

And in the UK, NUTS-2 and NUTS-3 at least are artificial classifications
that nobody would use.

Seriously, look
http://en.wikipedia.org/wiki/NUTS:UK

The problem isn't that NUTS defines made up groups of things to go between
other levels, it's just that it ignores actual administrative divisions and
makes its own ones by agglomeration, that are roughly the same population
size as each other.

Meanwhile, in OSM, admin_level is working out quite well.

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

Re: [OSM-talk] Slippy map - clickable POI

[Sven Grüner]

Martijn van Oosterhout schrieb:
>>  Thing is if you look at the code(line 70+) you'll see I'm manually entering
>> in the lat/lon box where each symbol appears. Not ideal, especially when the
>> POI are in the map data.
> 
> You need something on the server to get the POI data on the fly as in:
> http://dev.openstreetmap.org/~kleptog/pois/pois.html

Or as in:
http://www.lenz-online.de/divers/osm/osm5.htm

regards, Sven

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

Re: [OSM-talk] Contours on the Cycle Map

[Martin Simon]

2008/2/19, Andy Allan <[EMAIL PROTECTED]>:
> On Feb 18, 2008 10:09 PM, Martin Simon <[EMAIL PROTECTED]> wrote:
>
> > What do you think about rendering amenity:shelter on the highest zoom
> > level(z13)? I thinnkthis could be useful on a cycle map and there are 
> > already
> > many of these features in OSM.
>
> Sure. Give me a couple of photos of what they look like in real life
> ("shelter" is too generic for me to be certain I'm thinking of the
> same thing), and a URL to where they should be showing up on the map
> so that I know where to look. And you'll need some patience too :-)

Great!

I don't have photos now, because I'm at work - but I already did some
icons for this feature, you can find them here:
http://wiki.openstreetmap.org/index.php/Proposed_features/Shelter

and here:
http://lists.openstreetmap.org/pipermail/talk-de/2007-November/004220.html


In this area there are some amenity=shelter and at least one
"amenity=shelter, fireplace=yes":
http://gravitystorm.co.uk/osm/?zoom=13&lat=6560916.65707&lon=806046.75871&layers=B00

Thanks!

-Martin!

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

[OSM-talk] Announcing a controllable Audio player and synchronisation with continuous sound tracks in JOSM

[David Earl]

Today's JOSM build (549) contains some much improved audio handling.

In particular, you can now use your dictaphone to record one long 
continuous audio file while you're surveying, collect waypoints on your 
GPS, and then in JOSM synchronise the audio with the waypoints and play 
each from waypoint individually. This means you're not forever having to 
pause and restart recording while surveying, or listen to hours of heavy 
breathing when playing back.

Also, audio is now threaded, which means it can be controlled while
playing, so as well as playing directly from a waypoint, you can pause 
and resume, jump forward and back, and from one waypoint to the next or 
previous.

Most of this won't affect you if you don't use audio. But there is a
flag you can set if the extra menu offends you (see below).

Here's the changes to JOSM:

1. When you open a GPX file, it always did extract waypoints from the
file and turn them into markers in their own layer. If you now right
click on that marker layer you can "Apply Audio" to the layer. Choose a
WAV file(*) and the markers all become audio markers. (Previously you'd 
have needed a GPX file with audio links already set for the waypoints).

2. If your GPS selectively names trackpoints (rather than separate 
waypoints), these can now be turned into Markers as well. Use "Markers 
from Named Points" on the GPX layer. You can also set the advanced 
option "markers.namedtrackpoints" to true and this will happen 
automatically when GPX is opened (i.e. named trackpoints are treated 
like waypoints).(**)

3. You can play audio for the markers by clicking the marker (that is
unchanged) - but it starts at the distance in to the audio that the
marker is timed offset from the first marker. (If you click another
marker while playing, it jumps straight to the one you just clicked).

4. There is an Audio menu with some controls on it. Note that the period
(full stop) key is the play/pause key accelerator. If you just play, it
will play the audio for the first audio marker in the first marker 
layer. Press again to pause (or more likely press full stop) (it
may take up to 0.5sec to actually pause). Play again then resumes. Click
the marker again to play from that marker. Forward and back jump 10
seconds (or whatever value you set in the option
"audio.forwardbackamount" ***). And you can advance to the next or 
previous marker with those buttons. If you use these a lot, you will 
quite likely want to add the buttons to the toolbar to make a little 
player bar, using button preferences in the usual way.

5. You will want to synchronize with a marker. You can do this with any 
audio marker (e.g. if you did do a pause part way through so the sound 
track gets out of step), but usually it will be the first one - you 
would say "NOW" into your recorder at the same time as creating the 
waypoint on your GPS.

Then in JOSM, play the marker you want to sync on until you get to the
"NOW" and pause it. Then use right click on the marker layer and select
"Synchronize Audio". Then when you play a marker it will adjust the
playing position accordingly. So if when you got to making waypoint 54
you said "point 54: pub called Royal Oak on left", when you click on 
audio marker 54 it should play that phrase immediately.

There is a one second lead in (i.e. it starts a second earlier than the 
offset), but you can adjust this with "audio.leadin" (incuding negative 
amounts so the playing can skip a short interval after the waypoint, if 
you find it hard to start talking into the dictaphone).

6. Previously waypoints are named/numbered on the map, but when they
were displayed as audio, only the icon appeared. Now, if you set the
advanced setting "marker.buttonlabels" to true, it will also show you
the name/number, so you can relate to what you said into the dictaphone.

7. If you don't want to see the Audio menu at all, set
"audio.menuinvisible" to true.

8. One peculiarity of the previous behaviour was that if you clicked to
add a node on top of an audio marker it _also_ played the audio. It
still does (I thought about various alternative ways to activate the
marker, because you often want a node just where the marker is).
However, it no longer activates the audio (or image, or link marker) if
you mouse down outside the button. This means you can at least make your
node and then drag it into position on top of the marker icon without it
playing.


David


(*) What WAV files it plays is dependent on the Java Audio System. I
found that it won't play the 32-bit framed wave files that come out of
my Olympus Digital Voice Recorder. However, a conversion using Audacity
only takes a few seconds even on a long mapping session. The minimum
Java will play seems to be 8,000 samples per second with 8 or 16-bit
samples (the Olympus does 8,000 but with 32 bit floating point samples).
Maemo-recorder on my Nokia N810 was fine (though quiet, but that was a
microphone/recorder problem I think).

(**) Maemo-mapper on 

Re: [OSM-talk] displayed width of roads

[Andy Allan]

On Feb 18, 2008 11:21 PM, Frederik Ramm <[EMAIL PROTECTED]> wrote:
> Hi,
>
> > > By co-incidence, I was in contact with another mapper who's been doing
> > > something like this to make low zoom osmarender rendering a bit
> > > prettier. What's everybody's opinion of this kind of practice? Is it
> > > not an example of compromising the data (which we want to endure) to
> > > work around a temporary deficiency in one particular renderer?
> >
> > If the slip roads are not really underneath the other roads then
> > yes it is definitely wrong (IMHO). The layer tag is meant to describe
> > the physical ordering of the roads on the ground.
>
> I've had a similar situation on the talk-de list where some people
> seem to have started adding layer=1 to tram tracks. I don't like this
> all that much (a bridge leading over a road with tram tracks would
> then need to be layer=2 etc) but it's hard to argue with them since
> the tram tracks *are* on top of the road. The layer tag doesn't say by
> how much...

I think it's safe to assume that two ways on different layers should
allow the users of the lower layer to pass under the users of the
upper layer. I would presume that the cars can't drive *under* the
tram tracks, so therefore they are on the same layer.

You could politely encourage everyone to figure out where the bug in
the rendering is, and either file trac ticket or submit a patch. The
more details, examples, clarity of explanation and so on the better.

Cheers,
Andy

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

Re: [OSM-talk] displayed width of roads

[Dave Stubbs]

On Feb 18, 2008 11:21 PM, Frederik Ramm <[EMAIL PROTECTED]> wrote:
> Hi,
>
> > > By co-incidence, I was in contact with another mapper who's been doing
> > > something like this to make low zoom osmarender rendering a bit
> > > prettier. What's everybody's opinion of this kind of practice? Is it
> > > not an example of compromising the data (which we want to endure) to
> > > work around a temporary deficiency in one particular renderer?
> >
> > If the slip roads are not really underneath the other roads then
> > yes it is definitely wrong (IMHO). The layer tag is meant to describe
> > the physical ordering of the roads on the ground.
>
> I've had a similar situation on the talk-de list where some people
> seem to have started adding layer=1 to tram tracks. I don't like this
> all that much (a bridge leading over a road with tram tracks would
> then need to be layer=2 etc) but it's hard to argue with them since
> the tram tracks *are* on top of the road. The layer tag doesn't say by
> how much...
>

People take things written down too seriously, I'd argue that if a
human being can step over it it doesn't count (at a bare minimum).
I'm sure they think this too but just want tram tracks to appear above
roads, which is probably a sensible idea, but this isn't the way to go
about it.

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

Re: [OSM-talk] Contours on the Cycle Map

[Andy Allan]

On Feb 18, 2008 4:46 PM, Keith Sharp <[EMAIL PROTECTED]> wrote:

> This is great!  Any chance of a write up on how you did this?

It involves a GPS, two bits of string, a barometer and a long weekend
walking in circles around every hillside in the country...

In reality, it's fairly easy, and is based on using SRTM data and
gdal_contour to create the shapefiles, with a few basic scripts to tie
everything together. I'll make a page on the wiki with all the code to
get from NASA to the rendered contours on it the next time I have an
hour free.

Cheers,
Andy

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

Re: [OSM-talk] Contours on the Cycle Map

[Andy Allan]

On Feb 18, 2008 10:09 PM, Martin Simon <[EMAIL PROTECTED]> wrote:

> What do you think about rendering amenity:shelter on the highest zoom
> level(z13)? I thinnkthis could be useful on a cycle map and there are already
> many of these features in OSM.

Sure. Give me a couple of photos of what they look like in real life
("shelter" is too generic for me to be certain I'm thinking of the
same thing), and a URL to where they should be showing up on the map
so that I know where to look. And you'll need some patience too :-)

> Sadly, it seems to be frozen in a proposal state forever and is therefore not
> rendered on the two main maps yet.

No worries, it can go on the cycle map if it's useful, regardless of
how the voting is getting on. It can always be changed later if the
tagging changes, and I can still render deprecated tags during the
transition and so on.

Cheers,
Andy

> -Martin
>
>
> ___
> 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] Slippy map - clickable POI

[Martijn van Oosterhout]

On Feb 18, 2008 9:01 PM, Gregory <[EMAIL PROTECTED]> wrote:
> I've created an openlayers slippy map here (the tiles are via kosmos):
>  http://www.livingwithdragons.com/maps/slippytest.php
>
> And if you click on any of the pub symbols, you get a pop up (well text
> displaying at the side on the page would be nicer, but I rekon I can figure
> that out).
>  Thing is if you look at the code(line 70+) you'll see I'm manually entering
> in the lat/lon box where each symbol appears. Not ideal, especially when the
> POI are in the map data.

You need something on the server to get the POI data on the fly as in:
http://dev.openstreetmap.org/~kleptog/pois/pois.html

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

[OSM-talk] OSM flyer

[Frederik Ramm]

Hi,

   we (that's Y.T. and the folks on talk-de) have created an OSM flyer
that we can hand out to folks who ask us what we're doing. 

The flyer is DIN A7 sized (74mm wide and 105mm high) and has 8 pages
(8 pages sounds a lot but it's just one stripe of paper 105mm high and
296mm wide, zig-zag folded three times). We're trying to get the most
important things across: Look how cool we are, and it's all free, and
this is something else than free as in beer, and this is how we do it.

We have printed 5,000 copies (it's not really expensive - 200 Euros
for the lot, and some online printers would have done it for 150) and
we'll try to distribute them widely within the community so that every
mapper has a few of them with him when he's on the road.

Here's how it looks like:

front page - 
http://svn.openstreetmap.org/misc/pr_material/german_flyer_2008-01/osmflyer1.png
rear page - 
http://svn.openstreetmap.org/misc/pr_material/german_flyer_2008-01/osmflyer2.png

Takes some imagination to do the zig-zag fold in your head but I think
you'll cope ;-)

The design has been done in Inkscape, and all the raw material and a
README file is in SVN under

/misc/pr_material/german_flyer_2008-01/

so if anyone wants to do something similar for their area of
interest, just re-use anything you want. I'll even translate the text
for you if there's interest. 

Bye
Frederik

PS: I like Inkscape a lot, but whenever I do stuff for printing I run
into those nasty CMYK problems. Inkscape creates RGB PDFs, printers
want CMYK PDFs. You can auto-convert them but without a calibrated
screen or printer you never know how it's going to look like in print.
I guess this can only be solved by expensive equipment - I ended up
paying 50 Euros extra for a print designer to make me a proof on his
inkjet printer...

PPS: If you read the first letter of each paragraph in sequence, they
spell out "P.o.t.l.a.t.c.h.m.u.s.t.d.i.e."

PPPS: Just kidding to get Richard's attention ;-)

-- 
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] User umehlig and some really nasty edits

[Frederik Ramm]

Hi,

> And I ask: what is the value of the `id' attribute of the object in  
> question when the ID hasn't been assigned yet? Today I know the answer 

So why not just put it in the Wiki? Every misunderstanding that is
subsequently resolved is a chance to improve our documentation. I've
added a note about ids being assigned by the server.

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] Osmosis and Bounding Boxes

[Frederik Ramm]

Hi,

>If your goal is to have the results of all three bounding boxes in one
>file, you could tee the output of each bounding box, write one to a file,
>then pass the other to a merge task, then write out that merged set. It
>would be a complex command line but it should be possible.

You could also do the follwing in one Osmosis run:

* read input file
* cut out a bounding box or polygon that has the combined area of all
  the little ones
* "tee" this into n+1 streams
* write one of them to a file
* apply a further --bounding-box to the other "n" streams 
* write the other streams to a file

If your little boxes make up one big box then this is quite easy; if
the little boxes make up some other shape or are disjunct even then it
still works but requires a --bp in the first cut-out task.

Of course you could also simply tee the whole file into n+1 streams
and then apply the big box to one of them and the little ones to the
others but if your input is much bigger than your boxes then you're
wasting a lot of CPU there.

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] User umehlig and some really nasty edits

[Frederik Ramm]

Hi,

> Let me repeat onece more:
> * the DTDs say IDs are *required*

True, that should perhaps be changed. Sadly, the only way to do it
100% correct is to create an individual DTD for each of the operations
and we don't want that because it makes the whole thing too
complicated.

> * no paragraph or a single sentence says what values to put in the XML 
> for objects we are creating.

True, but there's a hint if you read the description of error code
412 ;-)

However let's not discuss whether you could have known something from
somewhere else, let's just improve the docs so that others find what
they need.

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] displayed width of roads

[Frederik Ramm]

Hi,

> > By co-incidence, I was in contact with another mapper who's been doing
> > something like this to make low zoom osmarender rendering a bit
> > prettier. What's everybody's opinion of this kind of practice? Is it
> > not an example of compromising the data (which we want to endure) to
> > work around a temporary deficiency in one particular renderer?
> 
> If the slip roads are not really underneath the other roads then
> yes it is definitely wrong (IMHO). The layer tag is meant to describe
> the physical ordering of the roads on the ground.

I've had a similar situation on the talk-de list where some people
seem to have started adding layer=1 to tram tracks. I don't like this
all that much (a bridge leading over a road with tram tracks would
then need to be layer=2 etc) but it's hard to argue with them since
the tram tracks *are* on top of the road. The layer tag doesn't say by
how much...

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