Re: [OSM-talk] how to tag travellers camps?

[Erik Johansson]

On Fri, Mar 28, 2008 at 7:21 AM, Lester Caine <[EMAIL PROTECTED]> wrote:

> We do then get into the discussion on *IF* we should record the position
> of
> such sites where they have been established without any regard to local
> planning rules.


If travelers doesn't have  anything against being "catalogued" I don't see
why not, and if any local businessman is against it/for it they can always
have an edit war about it. Seriously I don't think it's such a common
occurrence to warrant a long design discussion.

A more frequently seen thing would be:
landuse=Very_expensive_houses
security=none

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

Re: [OSM-talk] [tagging] RFC: railway=incline

[Tomáš Tichý]

Only small correction. There are railways which are cable driven for
only a section.  See for example Opicina Tramway
http://en.wikipedia.org/wiki/Opicina_Tramway. The same system use also
several logging and industrial railways (today I think mostly historic
or abandoned) to push cars over steep slopes.
With your modified proposal we can solve this with tagging cable
sections with traction=cable so this is no longer issue.
=TT=


>
>  However, as far as I am aware, the following do not exist:
>  * railways which are both cable- and rack-driven in the same section
>  * railways which are cable-driven for only a section
>  * funiculars connected to a main rail system
>
>  I've updated my proposal at
>  http://wiki.openstreetmap.org/index.php/Proposed_features/Incline_railway
>  to reflect this.
>
>  -Alex Mauer "hawke"
>
>
>
>
>  ___
>  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] Bounty for mapping Mottram and Tintwistle areas! (west of Machester on edge of peak district near Glossop)

[Peter Miller]

 

Back in January I asked
  if
there was anyone who could map the Mottram area for a bounty where there is
a controversial road being proposed. I am pleased to say that RichardB took
up the challenge and that the area has now well and truly mapped
 !

 

For your interest the public inquiry which was due to restart this week
(Easter 2008) has now been delayed again until October to allow the Highways
Agency more time to getting it traffic forecasts to work in the way they
want to.

 

This job does raise an important question about how to map and model
proposed roads. We have used the tags 'highway=trunk' and 'tunnel=yes' and
name='Mottram . bypass (proposed)', 'proposed=trunk' and added a note. It
would be better not to have to use the tunnel tag to get it to render
properly (especially as part of the road is indeed in a proposed tunnel
which we can't represent!). Btw, the Glossop Spur didn't render properly
this week under mapnik and I think (hope) it was because I used
'tunnel=true' not 'tunnel=yes'. I have changed the tags for the Glossop Spur
so that they are now identical to that for the main bypass and should render
properly next week. 

 

 

 

Regards,

 

 

 

Peter Miller

Ito World Ltd

 

 

 

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

Re: [OSM-talk] [tagging] RFC: railway=incline

[Sven Geggus]

Alex Mauer <[EMAIL PROTECTED]> wrote:

> I've updated my proposal at 
> http://wiki.openstreetmap.org/index.php/Proposed_features/Incline_railway 
> to reflect this.

To be serious, I don't like this pseudo object-oriented
railway:incline:traction= stuff at all.

So I would instead sugest to go for "traction="

As far as rendering is concerned, your proposol states "No rendering changes
required." This ist not true, as incline railways are currently _not_
rendered at all.

Regards

Sven

-- 
/*
 * Wirzenius wrote this portably, Torvalds fucked it up :-)
 */(taken from /usr/src/linux/lib/vsprintf.c)
/me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web

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

Re: [OSM-talk] how to tag travellers camps?

[Cartinus]

On Friday 28 March 2008 07:21:55 Lester Caine wrote:
> We do then get into the discussion on *IF* we should record the position of
> such sites where they have been established without any regard to local
> planning rules.

What is to discuss about that? AFAIK we are in the habit to always map what 
_is_ there, not whatever some officious suit says ought to be there.


-- 
m.v.g.,
Cartinus

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

Re: [OSM-talk] Tag proposal/approval system is too heavyweight

[Steve Hill]

On Thu, 27 Mar 2008, Gervase Markham wrote:

> On the other hand, feedback of the form "I don't like this proposal
> because it doesn't cover situation X, but I can neither provide a
> real-life example of X in the map, nor can I design a scheme which deals
> with it" is not helpful.

In the long term, this might be helpful - known problems with the proposal 
can be noted in the wiki for future reference.  This doesn't mean the 
proposal shouldn't go ahead and be approved, but it does mean that the 
problems with it are documented and can be fixed at a later date if 
someone figures out how to do it and/or if it actually starts becoming a 
problem.

I'm convinced that, where possible, we need to do a global update of the 
database when tags get depricated to try and reduce the amount of 
depricated stuff that could be replaced with a better solution.  (And I 
fully accept that some stuff _can't_ be automatically fixed up to newly 
approved tagging scheme - in these cases there needs to be a good way 
to alert people responsible for mapping an area that there are some tags 
that should be manually fixed up).

The problem I see with having a long-term mix of depricated and new tags 
is that the rendering rules get progressively more complex since they have 
to deal with both tagging schemes in order to have a complete map.

  - 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] JOSM update

[Steve Hill]

On Fri, 28 Mar 2008, Frederik Ramm wrote:

>  and you can also limit the
>  length of these GPS connection lines (draw.rawgps.max-line-length=x,
>  in metres), for those cases where you get crazy zig-zagging.

I had noticed a while ago that JOSM appeared to handle GPX files 
incorrectly (and presumably the same goes for GPX data retrieved from the 
OSM server) - Not sure if it has been fixed (I'm using a relatively old 
JOSM at the moment):

The GPX files consist of  elements (tracks), with each track 
containing one or more  element (track segment).  JOSM seemed to 
be joining the end of a  to the start of the next  rather 
than leaving them unconnected.  The  elements themselves are handled 
correctly though - they are left unconnected.

This might be the cause of a lot of the crazy zig-zagging (which actually 
makes the GPS data completely unusable in some locations - Nottingham, for 
example, is totally obscured by the zig-zagging lines if you ask JOSM to 
retrieve the GPS data from the server.)

Which brings me to another point - why not run a sanitiser across the 
database to try and remove obviously broken GPS data.  For example, if the 
distance between two GPS points exceeds several hundred metres they 
probably shouldn't be considered part of the same track segment so this 
could be fixed in the database itself.

  - 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] JOSM update

[Frederik Ramm]

Hi,

Steve Hill wrote:
> The GPX files consist of  elements (tracks), with each track 
> containing one or more  element (track segment).  JOSM seemed to 
> be joining the end of a  to the start of the next  
> rather than leaving them unconnected.  The  elements themselves are 
> handled correctly though - they are left unconnected.

I'll investigate that. However with data retrieved from the server, you 
don't even get the  structure, you just get a ton of individual 
points and have no chance of finding out whether they belong to the same 
segment or not!

(The original uploaded files are stored on the server, but what JOSM 
retrieves is a "distilled" view of them, rather than the individual files.)

Bye
Frederik


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

[OSM-talk] GeoFabrik update-frequency

[Jannis Achstetter]

Hello List, Hello Frederik,

I used the cut-outs from http://download.geofabrik.de/ quite often in 
the past when they were updated every two days. Now, the last update was 
at 19-Mar-2008. Did something get stuck or did you decide to lower the 
update-frequency of the regions since it creates high load on the server?


Jannis


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] JOSM update

[Steve Hill]

On Fri, 28 Mar 2008, Frederik Ramm wrote:

> I'll investigate that. However with data retrieved from the server, you don't 
> even get the  structure, you just get a ton of individual points and 
> have no chance of finding out whether they belong to the same segment or not!

Ouch - I hadn't realised that. :)

The problem I saw was for local GPX files - I was generating them from GPS 
data stored in a database and had originally used a single  
containing many  elements.  JOSM rendered them with every point 
joined to the next, even if those points were in separate  
elements.  I modified my GPX generator so that it used many  
elements, each with a single  and JOSM rendered that correctly.

When I saw a similar problem with the data downloaded from the server, I 
assumed it was probably the same problem, but didn't investigate further.

Anyway, I'll grab the latest JOSM and hopefully it'll make some areas a 
lot more readable without all those crazy tracks - good stuff. :)

  - 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] GeoFabrik update-frequency

[Frederik Ramm]

Hi,

> I used the cut-outs from http://download.geofabrik.de/ quite often in 
> the past when they were updated every two days. Now, the last update was 
> at 19-Mar-2008. Did something get stuck or did you decide to lower the 
> update-frequency of the regions since it creates high load on the server?

In theory, the updates happen as soon as a new planet file or a new 
daily diff is available. There was a hiccup after 19 March that broke 
updates, and the current situation is that there doesn't seem to be a 
current planet.bz2 (just a planet.gz!) and this is not read by the 
script. I'll fix it manually...

Bye
Frederik


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

Re: [OSM-talk] OSM poll

[Robert (Jamie) Munro]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sven Grüner wrote:
| SteveC schrieb:
|> See the poll at the bottom right hand corner, and vote OSM:
|>
|> http://www.directionsmag.com/
|
| I think those last three words were redundant ;-)
| (at least when adressing this list)
|
| WTH would anyone want to contribute to NavTeq & Co.

I have contributed data to TomTom MapShare (just a couple of corrections
to streets that don't allow vehicles) because it meant that I can be
sent a more sensible route by my device, and get a more accurate arrival
time. It benefits me, and it's really easy, so I did it. If only OSM
could be so easy...

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

iD8DBQFH7Nmkz+aYVHdncI0RAll2AJ0V0paa4sAk3z+3lTIJvIVyyElbRQCgp82y
qgm4V2Y20LW2Ss4SRKNN4iI=
=zIlj
-END PGP SIGNATURE-

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

Re: [OSM-talk] Mapping Mottram and Tintwistle proposed bypass

[Robert (Jamie) Munro]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter Miller wrote:
|
| This job does raise an important question about how to map and model
| proposed roads. We have used the tags ‘highway=trunk’ and ‘tunnel=yes’
| and name=’Mottram … bypass (proposed)’, ‘proposed=trunk’ and added a
| note. It would be better not to have to use the tunnel tag to get it to
| render properly (especially as part of the road is indeed in a proposed
| tunnel which we can’t represent!). Btw, the Glossop Spur didn’t render
| properly this week under mapnik and I think (hope) it was because I used
| ‘tunnel=true’ not ‘tunnel=yes’. I have changed the tags for the Glossop
| Spur so that they are now identical to that for the main bypass and
| should render properly next week.

The correct tagging is to put a start_date that is somewhere in the
future (i.e. the estimated date of completion of the project). I don't
think renderers support this yet - they just render it as a normal road.
They should render it as under construction (or not at all) if the date
is in the future, and normally otherwise. Similarly for end_date. Dates
should be in -MM-DD format as this is the most easily machine
readable. I think renderers should allow partial dates - so if you know
something will open in 2010, but not what month, you can just put
start_date=2010, or if you know it's February start_date=2010-02.

I also think renderers should ignore things after a space, so you can
put "start_date=2010-01-01 approximately" or "start_date=2010 proposed"
or other unforeseen uses.

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

iD8DBQFH7OSOz+aYVHdncI0RAuWKAKD8Zfojnl07nhH78z72H4bs4pgRGQCfZLnl
s1g5bSrPwSpHRz899DtZc20=
=kaiQ
-END PGP SIGNATURE-

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

Re: [OSM-talk] JOSM update

[Steve Hill]

On Fri, 28 Mar 2008, Frederik Ramm wrote:

> * It is now possible to have arrows on the lines connecting GPS
>  points (draw.rawgps.direction=true),

I'm seeing a couple of slightly odd things with the GPS direction arrows:
(screenshot) http://www.nexusuk.org/~steve/josm-gpsarrows.png

They are pointing the wrong way - the blue motorway loop in the screen 
shot is traversed in the anticlockwise direction, but the arrows on the 
GPS track are showing it to be clockwise (seems to be the case for all the 
GPS tracks, so this isn't just an odd data set).

Also, I seem to be getting a few extraneous arrows which always point 
East (visible on the right hand side of the motorway loop.

  - 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] JOSM update

[Frederik Ramm]

Hi,

> They are pointing the wrong way - the blue motorway loop in the  
> screen shot is traversed in the anticlockwise direction, but the  
> arrows on the GPS track are showing it to be clockwise (seems to be  
> the case for all the GPS tracks, so this isn't just an odd data set).

Are you saying every single arrow points the wrong way? Because that  
would be an easy fix to make ;-)

> Also, I seem to be getting a few extraneous arrows which always  
> point East (visible on the right hand side of the motorway loop.

This happens when lines of length 0 are drawn. I suspect that those  
tracks that suffer from the "east arrows" have been uploaded twice,  
so that every point in them occurs twice, but I'll check that again.  
Maybe JOSM should be instructed to omit these arrows.

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] JOSM update

[Steve Hill]

On Fri, 28 Mar 2008, Frederik Ramm wrote:

> Are you saying every single arrow points the wrong way? Because that would be 
> an easy fix to make ;-)

Yes, seems to be the case :)

> This happens when lines of length 0 are drawn. I suspect that those tracks 
> that suffer from the "east arrows" have been uploaded twice, so that every 
> point in them occurs twice, but I'll check that again. Maybe JOSM should be 
> instructed to omit these arrows.

Ah, ok - that makes sense.

  - 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] JOSM update

[Steve Hill]

On Fri, 28 Mar 2008, Steve Hill wrote:

>> Are you saying every single arrow points the wrong way? Because that would be
>> an easy fix to make ;-)
>
> Yes, seems to be the case :)

To complicate things more, the direction arrows on data imported from a 
local GPX file are the right way around, so this problem is only affecting 
data being retrieved from the OSM server.

  - 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] how to tag travellers camps?

[Alex S.]

graham wrote:
> Does anyone have any ideas for tagging traveller's camps? There are 
> quite a few round my way, long-term caravan sites with hard surfaces, 
> AFAIK all gypsy and not open to random caravanners.
> landuse = travellers_camp?  Or 'gypsy site'? I'm trying not to fall 
> between lack of political correctness and something that will be 
> misunderstood in any language but english..

Around here (USA), we call those 'membership campgrounds'.


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

Re: [OSM-talk] JOSM update

[Cartinus]

On Friday 28 March 2008 00:37:09 Frederik Ramm wrote:
> * It is now possible to have arrows on the lines connecting GPS
>   points (draw.rawgps.direction=true), and you can also limit the
>   length of these GPS connection lines (draw.rawgps.max-line-length=x,
>   in metres), for those cases where you get crazy zig-zagging. Caveat
>   emptor, using the max-line-length option will slow things down a
>   bit. These config options have to be set manually (via the
>   expert preferences panel or with a text editor in the preferences
>   file).

This is a nice feature, however...

If you download the gps point in the following bounding box:
http://www.openstreetmap.org/index.html?mlat=51.47889867327745&mlon=4.960084220112989&zoom=16
Then set the max-line-length option. You'll see that not just the long segment 
disappears, but everything that comes after it in the track is gone. I doubt 
this is what you intended.

-- 
m.v.g.,
Cartinus

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

[OSM-talk] Possibly interesting GPS navigation product for symbian phones

[Robert (Jamie) Munro]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Loadstone GPS is "Free satellite navigation software developed for
Symbian Mobile/phones using the Series60 platform. Although
Loadstone-GPS is a useful navigational tool for everyone, it is
particularly useful for blind and visually impaired people using screen
readers..."

http://www.loadstone-gps.com/

This mailing list post says they are looking at Open Street Map data:

http://www.loadstone-gps.com/pipermail/loadstone/2007-October/002371.html

Has anyone heard of this or tried it out?

I've added a wiki page about them:
http://wiki.openstreetmap.org/index.php/Loadstone

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

iD8DBQFH7Qroz+aYVHdncI0RAoT4AKDdV8t5+UNLaLuo616RTclCq8ZWowCgv5cL
AEBNwXaiorafPQ9h6vFzSUw=
=nl6k
-END PGP SIGNATURE-

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

Re: [OSM-talk] Cycle lanes

[Andy Allan]

On Mon, Mar 24, 2008 at 7:39 PM, Ben Laenen <[EMAIL PROTECTED]> wrote:
>
>  OK, I've googled a bit for images of cycleways to get an idea about when
>  other people would tag a cycleway as a separate highway... (sorry, it's
>  a bit of a Belgium-centric selection...)

[snip]

Excellent stuff. I much prefer that these discussions are based on
real life situations than hypotheticals.

I'd tag every one of those as highway=cycleway on a separate way, if I
had the time and the patience. If I was busy, I would see
cycleway=track as being a stop-gap, and someone else could model them
as separate ways when they had the time (in the same way that there's
nothing wrong with a parking node when you can't/don't want to draw
the area in full).

If, however, someone came along and removed my separate ways and added
cycleway=track to the road I would be very cross!

Cheers,
Andy

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

Re: [OSM-talk] JOSM update

[Raphael Mack]

Am Freitag, 28. März 2008 schrieb Steve Hill:
> On Fri, 28 Mar 2008, Steve Hill wrote:
> >> Are you saying every single arrow points the wrong way? Because that
> >> would be an easy fix to make ;-)
> >
> > Yes, seems to be the case :)
>
> To complicate things more, the direction arrows on data imported from a
> local GPX file are the right way around, so this problem is only
> affecting data being retrieved from the OSM server.

mh, I guess this cannot be fixed in josm, since the the server returns the 
stored gps points in arbitrary order. I would even suggest not to draw any 
direction arrows for gps data from the server.

Cheers,
Rapha

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

Re: [OSM-talk] JOSM update

[David Earl]

On 28/03/2008 16:50, Raphael Mack wrote:
> Am Freitag, 28. März 2008 schrieb Steve Hill:
>> On Fri, 28 Mar 2008, Steve Hill wrote:
 Are you saying every single arrow points the wrong way? Because that
 would be an easy fix to make ;-)
>>> Yes, seems to be the case :)
>> To complicate things more, the direction arrows on data imported from a
>> local GPX file are the right way around, so this problem is only
>> affecting data being retrieved from the OSM server.
> 
> mh, I guess this cannot be fixed in josm, since the the server returns the 
> stored gps points in arbitrary order. I would even suggest not to draw any 
> direction arrows for gps data from the server.

They can be sorted by timestamp, can't they? They do have timestamps AFAICS.

David


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

Re: [OSM-talk] JOSM update

[Tom Hughes]

In message <[EMAIL PROTECTED]>
  David Earl <[EMAIL PROTECTED]> wrote:

> On 28/03/2008 16:50, Raphael Mack wrote:
> > Am Freitag, 28. März 2008 schrieb Steve Hill:
> >> On Fri, 28 Mar 2008, Steve Hill wrote:
>  Are you saying every single arrow points the wrong way? Because that
>  would be an easy fix to make ;-)
> >>> Yes, seems to be the case :)
> >> To complicate things more, the direction arrows on data imported from a
> >> local GPX file are the right way around, so this problem is only
> >> affecting data being retrieved from the OSM server.
> > 
> > mh, I guess this cannot be fixed in josm, since the the server returns the
> > stored gps points in arbitrary order. I would even suggest not to draw any
> > direction arrows for gps data from the server.
> 
> They can be sorted by timestamp, can't they? They do have timestamps AFAICS.

I believe that they are sorted by timestamp. What they aren't sorted
by is the track they came from so you might get points jumbled up from
different tracks.

The API deliberately tries to expose limited information about the
points for privacy reasons as some points may have come from traces
that are not public.

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] JOSM update / why does API return GPS points in descending order?

[Frederik Ramm]

Hi,

> mh, I guess this cannot be fixed in josm, since the the server returns the 
> stored gps points in arbitrary order. I would even suggest not to draw any 
> direction arrows for gps data from the server.

But they can't be too arbitrary since drawing lines in between the 
points would reveal a completely chaotic picture otherwise. I think 
David Earl is right about sorting by timestamp since this is what's in 
the API source:

points = Tracepoint.find_by_area(min_lat, min_lon, max_lat, max_lon, 
:offset => offset, :limit => TRACEPOINTS_PER_PAGE, :order => "timestamp 
DESC" )

... and the "DESC" nicely explains the observation that all arrows are 
in the wrong direction! I wonder why it is there. TomH?

Bye
Frederik

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

Re: [OSM-talk] JOSM update

[David Earl]

On 28/03/2008 17:02, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
>   David Earl <[EMAIL PROTECTED]> wrote:
> 
>> On 28/03/2008 16:50, Raphael Mack wrote:
>>> Am Freitag, 28. März 2008 schrieb Steve Hill:
 On Fri, 28 Mar 2008, Steve Hill wrote:
>> Are you saying every single arrow points the wrong way? Because that
>> would be an easy fix to make ;-)
> Yes, seems to be the case :)
 To complicate things more, the direction arrows on data imported from a
 local GPX file are the right way around, so this problem is only
 affecting data being retrieved from the OSM server.
>>> mh, I guess this cannot be fixed in josm, since the the server returns the
>>> stored gps points in arbitrary order. I would even suggest not to draw any
>>> direction arrows for gps data from the server.
>> They can be sorted by timestamp, can't they? They do have timestamps AFAICS.
> 
> I believe that they are sorted by timestamp. What they aren't sorted
> by is the track they came from so you might get points jumbled up from
> different tracks.

But the tracks are grouped and numbered too...

David


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

Re: [OSM-talk] JOSM update

[Tom Hughes]

In message <[EMAIL PROTECTED]>
  David Earl <[EMAIL PROTECTED]> wrote:

> On 28/03/2008 17:02, Tom Hughes wrote:
>
> > I believe that they are sorted by timestamp. What they aren't sorted
> > by is the track they came from so you might get points jumbled up from
> > different tracks.
> 
> But the tracks are grouped and numbered too...

In the database they are, yes. We only sort by timestamp though when
returing API data, not by track+timestamp.

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] JOSM update / why does API return GPS points in descending order?

[Richard Fairhurst]

Frederik Ramm wrote:

> ... and the "DESC" nicely explains the observation that all arrows are
> in the wrong direction! I wonder why it is there.

Because you want the most recent ones first?

cheers
Richard


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

Re: [OSM-talk] JOSM update / why does API return GPS points in descending order?

[Frederik Ramm]

Hi,

>> ... and the "DESC" nicely explains the observation that all arrows are
>> in the wrong direction! I wonder why it is there.
> 
> Because you want the most recent ones first?

Does any application *not* read all pages returned?

Bye
Frederik

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

Re: [OSM-talk] JOSM update / why does API return GPS points in descending order?

[Andy Robinson (blackadder)]

Frederik Ramm wrote:
>Sent: 28 March 2008 5:10 PM
>To: Raphael Mack
>Cc: talk@openstreetmap.org
>Subject: Re: [OSM-talk] JOSM update / why does API return GPS points in
>descending order?
>
>Hi,
>
>> mh, I guess this cannot be fixed in josm, since the the server returns
>the
>> stored gps points in arbitrary order. I would even suggest not to draw
>any
>> direction arrows for gps data from the server.
>
>But they can't be too arbitrary since drawing lines in between the
>points would reveal a completely chaotic picture otherwise. I think
>David Earl is right about sorting by timestamp since this is what's in
>the API source:

And since its rare for two people to have the same time period for the same
area by chance it generally works (just back to front). But of course that
cant be guaranteed, especially if the area is large.

Cheers

Andy

>
>points = Tracepoint.find_by_area(min_lat, min_lon, max_lat, max_lon,
>:offset => offset, :limit => TRACEPOINTS_PER_PAGE, :order => "timestamp
>DESC" )
>
>... and the "DESC" nicely explains the observation that all arrows are
>in the wrong direction! I wonder why it is there. TomH?
>
>Bye
>Frederik
>
>___
>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] Cycle lanes

[OJ W]

Interesting you should mention dual-carriageways -- there was some
discussion a while back:

http://wiki.openstreetmap.org/index.php/Proposed_features/Left/right_things

about how to "push things outwards" from road centrelines...



On Tue, Mar 25, 2008 at 2:18 PM, Lars Aronsson <[EMAIL PROTECTED]> wrote:

> OJ W wrote:
>
> > Sounds very similar to the cycleway tagging in Bedford; treat it
> > as a separate way if it's not on the road, which makes it easy
> > to show if it takes detours away from the road:
>
> But I want it to be just next to the street, with no gap and no
> overlap, and getting this right requires that I know how it will
> be rendered (which I don't), and there still is no chance I would
> get it perfectly right.  It does make more sense to draw one way
> at the street's centerline and then use attributes to describe all
> the various lanes for cars, buses, bikes and sidewalks as a list
> with the width of each lane in metres.  How far away is it that
> Osmarender or Mapnik would render something like that?
>
> We have this problem with motorways already, that two ways
> (northbound and southbound) run perfectly parallel in reality, but
> on the map the distance between the ways is not always the same.
> If this was mechanics, I would put a spacer washer between them.
>
>
> --
>  Lars Aronsson ([EMAIL PROTECTED])
>  Aronsson Datateknik - http://aronsson.se
>
> ___
> 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] JOSM update / why does API return GPS points in descending order?

[Raphael Mack]

Am Freitag, 28. März 2008 schrieb Frederik Ramm:
> Hi,
>
> > mh, I guess this cannot be fixed in josm, since the the server returns
> > the stored gps points in arbitrary order. I would even suggest not to
> > draw any direction arrows for gps data from the server.
>
> But they can't be too arbitrary since drawing lines in between the
> points would reveal a completely chaotic picture otherwise. I think
> David Earl is right about sorting by timestamp since this is what's in
> the API source:
>
> points = Tracepoint.find_by_area(min_lat, min_lon, max_lat, max_lon,
>
> :offset => offset, :limit => TRACEPOINTS_PER_PAGE, :order => "timestamp
>
> DESC" )
>
> ... and the "DESC" nicely explains the observation that all arrows are
> in the wrong direction! I wonder why it is there. TomH?

Oh, this sounds nice. I expected, that the timestamps are not even stored 
in the db, since they are not included in the delivered gpx. Maybe one 
could implement this, when touching the code to change to ascending 
order? - This would allow to split the track into track segments which 
would help to draw arrows only if the time difference is less than some 
threshold...

Rapha

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

Re: [OSM-talk] JOSM update

[Robert (Jamie) Munro]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tom Hughes wrote:
| In message <[EMAIL PROTECTED]>
|   David Earl <[EMAIL PROTECTED]> wrote:
|
|> On 28/03/2008 16:50, Raphael Mack wrote:
|>> Am Freitag, 28. März 2008 schrieb Steve Hill:
|>>> On Fri, 28 Mar 2008, Steve Hill wrote:
|> Are you saying every single arrow points the wrong way? Because that
|> would be an easy fix to make ;-)
| Yes, seems to be the case :)
|>>> To complicate things more, the direction arrows on data imported from a
|>>> local GPX file are the right way around, so this problem is only
|>>> affecting data being retrieved from the OSM server.
|>> mh, I guess this cannot be fixed in josm, since the the server
returns the
|>> stored gps points in arbitrary order. I would even suggest not to
draw any
|>> direction arrows for gps data from the server.
|> They can be sorted by timestamp, can't they? They do have timestamps
AFAICS.
|
| I believe that they are sorted by timestamp. What they aren't sorted
| by is the track they came from so you might get points jumbled up from
| different tracks.
|
| The API deliberately tries to expose limited information about the
| points for privacy reasons as some points may have come from traces
| that are not public.

Why expose the timestamps of private tracks. Expose the order, but
please don't expose the timing - apart from the positions themselves,
this is the most private part of the data.

Thanks,

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

iD8DBQFH7S2Rz+aYVHdncI0RAmFbAKD8v03s1x1xh0ed6AsPkuSD27QS6ACgub70
2M8xpalyerW3RC/NwR5oRlo=
=19Pp
-END PGP SIGNATURE-

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

Re: [OSM-talk] Cycle lanes

[Frederik Ramm]

Hi,

> Interesting you should mention dual-carriageways -- there was some 
> discussion a while back:
> 
> http://wiki.openstreetmap.org/index.php/Proposed_features/Left/right_things

Thanks for bringing this to my attention, I have put a paragaph on the 
discussion page about why I strongly dislike direction-dependent tagging ;-)

Bye
Frederik


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

Re: [OSM-talk] JOSM update / why does API return GPS points in descending order?

[Richard Fairhurst]

Frederik Ramm wrote:

> Does any application *not* read all pages returned?

Well, in Potlatch the "download points in current area" is the primary  
method of reading tracklogs (as - mercifully - it doesn't have any  
access to your local file system), so yes, it does return only the  
most recent n000 points to avoid utterly boggling the server/your  
browser. That said, it doesn't use the XML API anyway so it's a bit of  
a moot point.

cheers
Richard


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

Re: [OSM-talk] JOSM update

[Frederik Ramm]

Hi,

> | I believe that they are sorted by timestamp. What they aren't sorted
> | by is the track they came from so you might get points jumbled up from
> | different tracks.
> |
> | The API deliberately tries to expose limited information about the
> | points for privacy reasons as some points may have come from traces
> | that are not public.
> 
> Why expose the timestamps of private tracks. Expose the order, but
> please don't expose the timing

That's exactly what happens. They are sorted by timestamp, but what's 
returned is only the latitude and longitude.

(If I were really bent on finding out the exact timestamp of a certain 
GPS point, I could do a "binary search attack" by uploading a trace that 
contains a point in the area I'm interested in, with a timestamp of, 
say, 2 years ago. Then download the GPS trace and see if my point is 
before or after the point I am interested in. Then upload another trace 
with a test point one year later or earlier, and so on. I would probably 
have to upload about 10 points to know exactly which day the GPS point 
was recorded on, and 5 more to know the hour of the day. But that would 
really be vandalism...)

Bye
Frederik


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

Re: [OSM-talk] Cycle lanes

[Ben Laenen]

On Friday 28 March 2008, Andy Allan wrote:
> I'd tag every one of those as highway=cycleway on a separate way, if
> I had the time and the patience. If I was busy, I would see
> cycleway=track as being a stop-gap, and someone else could model them
> as separate ways when they had the time (in the same way that there's
> nothing wrong with a parking node when you can't/don't want to draw
> the area in full).
>
> If, however, someone came along and removed my separate ways and
> added cycleway=track to the road I would be very cross!

I've started thinking along those lines as well now. Separate highways 
for cycleways could provide some more detail. But keep this "lower 
resolution" method for quick tagging, so it doesn't need gps tracks for 
each cycleway before one is able to say in OSM that the road has a 
cycleway.

However, if cycle tracks are separate ways, then cycle lanes like 
http://www.info.groenbrussel.be/images/random/fietspad.jpg should be as 
well IMHO (since the painted cycleways can just as well have all the 
extra tags as cycle tracks, they could just as well cross the street, 
be oneway or not, etc).

The talk about legislation in the UK in one of the earlier responses to 
one of my mails makes me wonder though if their cycle lanes are 
somewhat the same as our "fietssuggestiestroken" (bicycle suggestion 
strips) like http://www.maldegem.be/infokrant_april07/0205.jpg
The rules on it are quite simple: there are no rules for it :-). The 
strip is just part of the road, only in a different colour, but that 
has no meaning in traffic law whatsoever. Cars are allowed to drive on 
them whereas the one in the picture above cars can only cross them, and 
it doesn't give cyclists right of way over other traffic, whereas the 
first kind does.

Doesn't take away the fact that renderers have to be able to handle it 
though before it gives nice results, and that may be a lot of work as 
well for all I can see.

I also wonder about the exact interaction with sidewalks. Cycle tracks 
are often embedded into the sidewalk like this for example 
http://www.bttb.be/beelden/astridplein.JPG which is basically two 
footways on each side of the cycleway. How would one put such a 
situation in OSM?

Greetings
Ben

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

Re: [OSM-talk] Tag proposal/approval system is too heavyweight

[Karl Newman]

On Fri, Mar 28, 2008 at 5:52 AM, Steve Hill <[EMAIL PROTECTED]> wrote:

> On Thu, 27 Mar 2008, Gervase Markham wrote:
>
> > On the other hand, feedback of the form "I don't like this proposal
> > because it doesn't cover situation X, but I can neither provide a
> > real-life example of X in the map, nor can I design a scheme which deals
> > with it" is not helpful.
>
> In the long term, this might be helpful - known problems with the proposal
> can be noted in the wiki for future reference.  This doesn't mean the
> proposal shouldn't go ahead and be approved, but it does mean that the
> problems with it are documented and can be fixed at a later date if
> someone figures out how to do it and/or if it actually starts becoming a
> problem.
>
> I'm convinced that, where possible, we need to do a global update of the
> database when tags get depricated to try and reduce the amount of
> depricated stuff that could be replaced with a better solution.  (And I
> fully accept that some stuff _can't_ be automatically fixed up to newly
> approved tagging scheme - in these cases there needs to be a good way
> to alert people responsible for mapping an area that there are some tags
> that should be manually fixed up).
>
> The problem I see with having a long-term mix of depricated and new tags
> is that the rendering rules get progressively more complex since they have
> to deal with both tagging schemes in order to have a complete map.
>
>  - Steve
>

Well, if we're serious about deprecation, then that just means at some point
those tags are no longer rendered or recognized. Flagging those deprecated
tags with a validator would be a good first step.

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

Re: [OSM-talk] JOSM update / why does API return GPS points in descending order?

[bvh]

On Fri, Mar 28, 2008 at 05:37:19PM -, Andy Robinson (blackadder) wrote:
> And since its rare for two people to have the same time period for the same
> area by chance it generally works (just back to front). But of course that
> cant be guaranteed, especially if the area is large.

Or when there has been a mapping party with multiple groups in the
area...

cu bart

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

Re: [OSM-talk] JOSM update / why does API return GPS points in descending order?

[Karl Newman]

On Fri, Mar 28, 2008 at 12:37 PM, Andy Robinson (blackadder) <
[EMAIL PROTECTED]> wrote:

> Frederik Ramm wrote:
> >Sent: 28 March 2008 5:10 PM
> >To: Raphael Mack
> >Cc: talk@openstreetmap.org
> >Subject: Re: [OSM-talk] JOSM update / why does API return GPS points in
> >descending order?
> >
> >Hi,
> >
> >> mh, I guess this cannot be fixed in josm, since the the server returns
> >the
> >> stored gps points in arbitrary order. I would even suggest not to draw
> >any
> >> direction arrows for gps data from the server.
> >
> >But they can't be too arbitrary since drawing lines in between the
> >points would reveal a completely chaotic picture otherwise. I think
> >David Earl is right about sorting by timestamp since this is what's in
> >the API source:
>
> And since its rare for two people to have the same time period for the
> same
> area by chance it generally works (just back to front). But of course that
> cant be guaranteed, especially if the area is large.
>
> Cheers
>
> Andy
>
>
On the increasingly likely (as our userbase grows) chance that two or more
users upload tracks with overlapping times, would it be possible to do a
"group by" user so that the tracks will be logically clustered? I don't know
the table schema--I'm not even sure if that table has a "user" column.

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

Re: [OSM-talk] Tag proposal/approval system is too heavyweight

[simon]

> Well, if we're serious about deprecation, then that just means at some
> point
> those tags are no longer rendered or recognized. Flagging those deprecated
> tags with a validator would be a good first step.
>

Isn't this a job for maplint? Once the tags move to a 'soon to be retired'
stage, maplint should flag them. Given suitable notice, if any are still
left at the end of the period then they will 'magically' not be rendered
anymore.

I feel that it is important not to automatically fix tags, as this could
result in a custom render suddenly failing.

Mungewell.


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

Re: [OSM-talk] Tag proposal/approval system is too heavyweight

[simon]

> I feel that it is important not to automatically fix tags, as this could
> result in a custom render suddenly failing.
>

Sorry just to clarify, I don't think that it is right for OSM to
automatically fix tags.

If an individual user has to tools to automagically fix tags within an
area then that is probably OK, since it is more likely that they are
associated with the tags in the first place.

Mungewell.


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

Re: [OSM-talk] Tag proposal/approval system is too heavyweight

[simon]

>
> I feel that it is important not to automatically fix tags, as this could
> result in a custom render suddenly failing.
>

Sorry just to clarify, I don't think that it is right for OSM to
automatically fix tags.

If an individual user has to tools to automagically fix tags within an
area then that is probably OK, since it is more likely that they are
associated with the tags in the first place.

Mungewell.



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

Re: [OSM-talk] JOSM update

[David Earl]

On 28/03/2008 18:00, Frederik Ramm wrote:
> Hi,
> 
>> | I believe that they are sorted by timestamp. What they aren't sorted
>> | by is the track they came from so you might get points jumbled up from
>> | different tracks.
>> |
>> | The API deliberately tries to expose limited information about the
>> | points for privacy reasons as some points may have come from traces
>> | that are not public.
>>
>> Why expose the timestamps of private tracks. Expose the order, but
>> please don't expose the timing
> 
> That's exactly what happens. They are sorted by timestamp, but what's 
> returned is only the latitude and longitude.
> 
> (If I were really bent on finding out the exact timestamp of a certain 
> GPS point, I could do a "binary search attack" by uploading a trace that 
> contains a point in the area I'm interested in, with a timestamp of, 
> say, 2 years ago. Then download the GPS trace and see if my point is 
> before or after the point I am interested in. Then upload another trace 
> with a test point one year later or earlier, and so on. I would probably 
> have to upload about 10 points to know exactly which day the GPS point 
> was recorded on, and 5 more to know the hour of the day. But that would 
> really be vandalism...)

I should point out that you can't synchronize an audio track to a GPS 
track without the exact timing information.

But I'm confused now - if I look at GPS tracks on the third tab of the 
OSM home page, what I see is GPX style HTML with exact timestamps and 
ordered tracks. So if it is public there why suppress it when accessed 
through another route.

I'm also bemused why people are concerned about making this public anyway.

David


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

Re: [OSM-talk] [tagging] RFC: railway=incline

[Alex Mauer]

Sven Geggus wrote:
> 
> To be serious, I don't like this pseudo object-oriented
> railway:incline:traction= stuff at all.

Huh?  object oriented?  It's like that in order to prevent potential 
conflicts, not anything to do with object orientation.

> As far as rendering is concerned, your proposol states "No rendering changes
> required." This ist not true, as incline railways are currently _not_
> rendered at all.

Good point.  I've updated the proposal. (though of course, rendering 
incline railways wouldn't be required as such, but that's just semantics)


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

Re: [OSM-talk] Mapping Mottram and Tintwistle proposed bypass

[Peter Miller]

Thanks for that Robert. A few other questions:

1) How does one tag something that is being considered seriously (such as
the Mottram Tintwistle bypass), but which may well never get built? I think
I will just put the estimated build date given by the highways agency for
now. (I will also continue to use the tunnel trick to get it to render in
the mean time).

2) I have a more difficult job with the new Haughley Bends upgrade on the
A14. A new section of A14 is being opened in the summer 08 and then the old
carriageways will be closed for 6 months and will then re-emerge as a
tertiary road (the west carriageway) and a bridleway (the east carriageway)
for most of the old section in Dec08, although a couple of short bits will
be grubbed up entirely and some new linking bits will be created. Is there
any way of coding such a thing? I feel it may be better to create a
relationship around all of the old stuff and say that it is going to go on
the switchover date, and then separately model the new network for the
replacement. Currently one has to add dates to every single little section
of road and as the opening date slips one should really change all the dates
which would be bonkers. In reality when a scheme opens in parts one might
have a series of versions of the model to be used in turn.

I realise that I am pushing the model beyond its initial intentions but we
are going to need to have robust ways of dealing with change.



Regards,





Peter



> -Original Message-
> From: Robert (Jamie) Munro [mailto:[EMAIL PROTECTED]
> Sent: 28 March 2008 12:29
> To: Peter Miller; Talk Openstreetmap
> Subject: Re: [OSM-talk] Mapping Mottram and Tintwistle proposed bypass
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Peter Miller wrote:
> |
> | This job does raise an important question about how to map and model
> | proposed roads. We have used the tags 'highway=trunk' and 'tunnel=yes'
> | and name='Mottram . bypass (proposed)', 'proposed=trunk' and added a
> | note. It would be better not to have to use the tunnel tag to get it to
> | render properly (especially as part of the road is indeed in a proposed
> | tunnel which we can't represent!). Btw, the Glossop Spur didn't render
> | properly this week under mapnik and I think (hope) it was because I used
> | 'tunnel=true' not 'tunnel=yes'. I have changed the tags for the Glossop
> | Spur so that they are now identical to that for the main bypass and
> | should render properly next week.
> 
> The correct tagging is to put a start_date that is somewhere in the
> future (i.e. the estimated date of completion of the project). I don't
> think renderers support this yet - they just render it as a normal road.
> They should render it as under construction (or not at all) if the date
> is in the future, and normally otherwise. Similarly for end_date. Dates
> should be in -MM-DD format as this is the most easily machine
> readable. I think renderers should allow partial dates - so if you know
> something will open in 2010, but not what month, you can just put
> start_date=2010, or if you know it's February start_date=2010-02.
> 
> I also think renderers should ignore things after a space, so you can
> put "start_date=2010-01-01 approximately" or "start_date=2010 proposed"
> or other unforeseen uses.
> 
> Robert (Jamie) Munro
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFH7OSOz+aYVHdncI0RAuWKAKD8Zfojnl07nhH78z72H4bs4pgRGQCfZLnl
> s1g5bSrPwSpHRz899DtZc20=
> =kaiQ
> -END PGP SIGNATURE-


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

Re: [OSM-talk] JOSM update

[Frederik Ramm]

Hi,

> I should point out that you can't synchronize an audio track to a GPS  
> track without the exact timing information.
>
> But I'm confused now - if I look at GPS tracks on the third tab of the  
> OSM home page, what I see is GPX style HTML with exact timestamps and  
> ordered tracks. So if it is public there why suppress it when accessed  
> through another route.

That's a common misunderstanding.

We store GPX tracks in two forms. One, the original GPX files, exactly
as uploaded, with whatever extra private information your GPS emitted
("waypoint 001, note=this is where I kissed Joanna yesterday"). These
are stored on the server, but only accessible to the public in this
"full" form if you explicitly make them public. (There's an API call
to retrieve lists of trace files and download the individual files if
desired.)

Furthermore, any uploaded track, public or not, is processed by a
daemon and the individual GPS points with timestamps and a link back
to the file where they came from are stored in the database. The API
will, on request, return all GPS points within a certain bounding box,
but you will ONLY get GPS points, ordered by timestamp but you don't
see the timestamp, and you will not get the track structure or the
note about Joanna.

Apart from the web site where you can browse the individual tracks,
all clients use the second interface that gives access to all GPS
points, but not the extra data.

This means that you will never be able to match an audio track to GPS
points downloaded via the API "all GPS points in bbox" call, but
that's probably not what you want anyway.

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

[OSM-talk] someone mapping with video?

[mariner]

hi guys..

is someone out there mapping with the help of a video camera?
how do you do it?
what are the problems?

cheers,
mariner



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

Re: [OSM-talk] Tag proposal/approval system is too heavyweight

[Frederik Ramm]

Hi,

> > I feel that it is important not to automatically fix tags, as this could
> > result in a custom render suddenly failing.
> 
> Sorry just to clarify, I don't think that it is right for OSM to
> automatically fix tags.

I agree, to a point. I would be very unhappy if out of the voting
mechanism sprang some sort of automatic juggernaut that would simply
throw over everything that five people have decided to be
"deprecated". Changing the whole database must not become a routine
operation to happen after a vote; it should only happen on a
case-by-case basis after careful consideration about the impact, and
only if there's general agreement in the community (a three-against-
two majority does not count as general agreement). Individual
mappers are still the authority, and if we change what they have
mapped against their will, chances are that some of them will just
change it back.

However there are some cases where I think it's perfectly ok to make
automated changes without further ado, and these are the cases where
it is very likely that spelling errors or misunderstandings have
occurred (e.g. changing residental to residential, or changing
religion=protestant to religion=christian,denomination=protestant).

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] JOSM update / why does API return GPS points in descending order?

[Frederik Ramm]

Hi,

> > Does any application *not* read all pages returned?
> 
> Well, in Potlatch the "download points in current area" is the primary  
> method of reading tracklogs (as - mercifully - it doesn't have any  
> access to your local file system)

"Whoooa! Potlatch has just ruined my personal files!"

, so yes, it does return only the most recent n000 points to avoid
> utterly boggling the server/your browser. That said, it doesn't use
> the XML API anyway so it's a bit of a moot point.

Right. I'll change JOSM to draw the arrows the other way for
GPS tracks downloaded from the server, but please don't forget to
speak up should you ever remove the DESC ordering ;-)

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] JOSM update / why does API return GPS points in descending order?

[80n]

On Fri, Mar 28, 2008 at 5:37 PM, Andy Robinson (blackadder) <
[EMAIL PROTECTED]> wrote:

> Frederik Ramm wrote:
> >Sent: 28 March 2008 5:10 PM
> >To: Raphael Mack
> >Cc: talk@openstreetmap.org
> >Subject: Re: [OSM-talk] JOSM update / why does API return GPS points in
> >descending order?
> >
> >Hi,
> >
> >> mh, I guess this cannot be fixed in josm, since the the server returns
> >the
> >> stored gps points in arbitrary order. I would even suggest not to draw
> >any
> >> direction arrows for gps data from the server.
> >
> >But they can't be too arbitrary since drawing lines in between the
> >points would reveal a completely chaotic picture otherwise. I think
> >David Earl is right about sorting by timestamp since this is what's in
> >the API source:
>
> And since its rare for two people to have the same time period for the
> same
> area by chance it generally works (just back to front). But of course that
> cant be guaranteed, especially if the area is large.
>

It would happen though when there's been a mapping party.




>
> Cheers
>
> Andy
>
> >
> >points = Tracepoint.find_by_area(min_lat, min_lon, max_lat, max_lon,
> >:offset => offset, :limit => TRACEPOINTS_PER_PAGE, :order => "timestamp
> >DESC" )
> >
> >... and the "DESC" nicely explains the observation that all arrows are
> >in the wrong direction! I wonder why it is there. TomH?
> >
> >Bye
> >Frederik
> >
> >___
> >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] potential import of official Irish lighthouse data

[OJ W]

In case anyone missed it, there's a discussion on the OSM diaries system:

http://www.openstreetmap.org/user/Dolphin3900/diary/1233
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] someone mapping with video?

[OJ W]

I normally use a notebook and GPS, but I do sometimes use a video camera too

I've got an ATC2000, which is about £90, waterproof, droppable, and either
mounts on either bike handlebars or you can attach it to the passenger
headrest in a car:

http://www.oregonscientific.co.uk/prod_allterraincamera.htm

That does about 1.5 hours of 600x480 resolution at 30fps onto a 2GB SD card,
or longer at lower resolutions / bigger SD card.

The resolution is just about good enough to read large roadsigns if you go
past them reasonably slowly.   It's good for noticing rows of
shops/houses/forests etc. at the side of the road while you're driving.
While cycling, you can use it to record roadsigns if you just point the
camera at them from a few metres away and pause for a second or so.

I can send you some sample clips, but they're about 600MB each so shout if
you want them.

I'm not aware of any special software for converting video + GPX into a 3d
textured map of the route, so I'll be watching this discussion to see if
anyone suggests some...

Regards,

OJW


p.s. sound quality is awful, so don't use this one if you want
voice-recordings...




On Fri, Mar 28, 2008 at 9:33 PM, mariner <[EMAIL PROTECTED]> wrote:

> hi guys..
>
> is someone out there mapping with the help of a video camera?
> how do you do it?
> what are the problems?
>
> cheers,
> mariner
>
>
>
> ___
> 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] someone mapping with video?

[mariner]

thanks for your reply. two more questions...

1.
are you happy with the atc2000? I was thinking about buying one. But the
price is a bit high for VGA resolution.
a  sample clip while doing OSM usage would be nice... do you have
possibilities to put one online?

are SD cards bigger than 2GB supported? on the page I saw somewhere the
limit of 2GB.

2.
how do you adjust the movie to the coordinates of the gps? do you watch
the movie, while your painting into the OSM database?

cheers,
mariner


OJ W wrote:
> I normally use a notebook and GPS, but I do sometimes use a video
> camera too
>
> I've got an ATC2000, which is about £90, waterproof, droppable, and
> either mounts on either bike handlebars or you can attach it to the
> passenger headrest in a car:
>
> http://www.oregonscientific.co.uk/prod_allterraincamera.htm
>
> That does about 1.5 hours of 600x480 resolution at 30fps onto a 2GB SD
> card, or longer at lower resolutions / bigger SD card.
>
> The resolution is just about good enough to read large roadsigns if
> you go past them reasonably slowly.   It's good for noticing rows of
> shops/houses/forests etc. at the side of the road while you're
> driving.  While cycling, you can use it to record roadsigns if you
> just point the camera at them from a few metres away and pause for a
> second or so.
>
> I can send you some sample clips, but they're about 600MB each so
> shout if you want them.
>
> I'm not aware of any special software for converting video + GPX into
> a 3d textured map of the route, so I'll be watching this discussion to
> see if anyone suggests some...
>
> Regards,
>
> OJW
>
>
> p.s. sound quality is awful, so don't use this one if you want
> voice-recordings...
>  
>
>
>
> On Fri, Mar 28, 2008 at 9:33 PM, mariner <[EMAIL PROTECTED]> wrote:
>
> hi guys..
>
> is someone out there mapping with the help of a video camera?
> how do you do it?
> what are the problems?
>
> cheers,
> mariner
>
>
>
> ___
> 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] Mottram Bypass - proposed roads

[Richard Bullock]

>
> 1) How does one tag something that is being considered seriously (such as
> the Mottram Tintwistle bypass), but which may well never get built? I 
> think
> I will just put the estimated build date given by the highways agency for
> now. (I will also continue to use the tunnel trick to get it to render in
> the mean time).
>
> 2) I have a more difficult job with the new Haughley Bends upgrade on the
> A14. A new section of A14 is being opened in the summer 08 and then the 
> old
> carriageways will be closed for 6 months and will then re-emerge as a
> tertiary road (the west carriageway) and a bridleway (the east 
> carriageway)
> for most of the old section in Dec08, although a couple of short bits will
> be grubbed up entirely and some new linking bits will be created. Is there
> any way of coding such a thing? I feel it may be better to create a
> relationship around all of the old stuff and say that it is going to go on
> the switchover date, and then separately model the new network for the
> replacement. Currently one has to add dates to every single little section
> of road and as the opening date slips one should really change all the 
> dates
> which would be bonkers. In reality when a scheme opens in parts one might
> have a series of versions of the model to be used in turn.
>
> I realise that I am pushing the model beyond its initial intentions but we
> are going to need to have robust ways of dealing with change.
>
>
If it's genuinely under construction now, then if you tag as

 (or any other normal highway tag)

Then it will render as a dashed line in Osmarender (but not currently on 
Mapnik)

e.g. see the A5117 / M56 improvement scheme in West Cheshire
http://www.openstreetmap.org/?lat=53.2399&lon=-2.9631&zoom=14&layers=0BFT

I don't see much point in adding dates specifically. I don't think we should 
expect it all to show up as complete in the database magically on the date. 
It's not particularly difficult to change it to a highway=trunk (or 
whatever) when it's open. It's rare for a road scheme to open exactly on the 
stated date anyway, and that's assuming that the powers that be are going to 
be more specific than say, "opening Summer 08".

For the Haughley Bends (finally sorting that bit out), easiest is to tag as 
highway=construction,construction=trunk for the new section. When that's 
open, tag the old road as highway=construction,construction=tertiary, then 
when each bit opens, it can be tagged as normal.

Richard B 


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

Re: [OSM-talk] import of dataset for new zealand

[Robin Paulson]

On 21/03/2008, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
>  >  in the second case,well i see this as unlikely. how any orgs are
>  >  willing to go to the cost of creating a duplicate data set for an area
>  >  (by which i mean same data, same area), when they can get one that
>  >  exists immediately?
>
>
> I know you think this is hypothetical but it's a very real problem. In
>  NL we got the AND data and in the next year or two we will get access
>  to the NWB, which is the map compiled by the govt. It's not clear at
>  all that one is going to be better than the other and merging them is
>  going to be a real problem.

sorry for the long delay in replying, been on holiday

ok, clearly not so hypothetical. in the case of two data sets being
merged, why can the 'source' tag not be updated to be 'source=AND,
NWB'  i realise it's proposed to be read-only, but there's no reason
the person reponsible for the second import couldn't be given
administrator privileges for the period when the second data import is
done. they upload the data, and at the same time the source tag is
added to. everyone else still only has read-only privileges for that
specific tag, but can edit anything else (position of objects, data in
other tags, as they see fit)

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

Re: [OSM-talk] import of dataset for new zealand

[Robin Paulson]

On 21/03/2008, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> What defines a major source? If I say I want my data to be displayed
>  with attribution on any application that uses OSM, I don't think
>  that's reasonable. We can reference them on the website, in a press
>  release, whatever. But keep it the hell away from the maps.

point taken, that was badly worded: i meant any source that puts usage
restrictions on their data, such as 'i want attribution clearly
displayed whenever our data is viewed'

which *generally* only happens and is *generally* only entertained (i
would imagine) for large orgs such as linz, AND, etc

it is perfectly reasonable for you (or any other user) to ask that
your data has special attribution, but as that user is likely
contributing less data than the likes of linz, osm are more likely to
say 'we can do without your (small) amount of data if you're going to
put those restrictions on it'

it's a balance - how much value does the data add, versus the cost (in
whatever terms, be it technical, ugliness, money, whatever) of
including it?

>  >  or how about as a separate, floating layer that can be turned on and
>  >  off? something on by default (again, at zoom 18 only)? when the user
>  >  zooms into the area, the layer is turned on, but they are asked
>  >  (subtly) if they want it off from that point onwards? would using
>  >  cookies to determine if they have been to that zoom level in that area
>  >  be workable?
>
>
> You're missing the point. If I run my own mapnik instance and make my
>  own stylesheet the has no attribution because I think it's ugly, can I
>  now be sued because I left it out?

if you break the license terms, yes

> I thought the whole point of this
>  project was to get away from crap like that...

well, partly. but the practicality is that we need a license that says
'do this if you want to use our data' to protect it from bad people,
so it's not unreasonable for people who donate large amounts to us to
do similar

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

Re: [OSM-talk] GML to OSM (Re: convert mapinfo POI to osm for uploading)

[maning sambale]

>  I made a PHP script for this quite some time ago. Unfortunately, it worked
>  only for 0.4 OSM API, so I (or anyone) should spend some time updating the
>  scripts to use the 0.5 data format.
>
>  http://svn.openstreetmap.org/applications/utils/import/gml2osm/
>
>  Besides that, customizing the script to parse custom tags should be pretty
>  easy.

Are there any updates on this script?  Desperately needed for a public
domain data available as GML.
http://gis.naga.gov.ph/pmwiki/pmwiki.php/Main/Data

maning

-- 
|-|--|
| __.-._ |"Ohhh. Great warrior. Wars not make one great." -Yoda |
| '-._"7' |"Freedom is still the most radical idea of all" -N.Branden|
| /'.-c |Linux registered user #402901, http://counter.li.org/ |
| | /T |http://esambale.wikispaces.com|
| _)_/LI
|-|--|

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