Re: [OSM-talk] [OSM-dev] The future of Potlatch

[Lester Caine]

SteveC wrote:
> On 2 May 2008, at 12:38, Christopher Schmidt wrote:
>> Some things don't require referential integreity: selecting ways/nodes
>> within a bounding box can't hurt the referential integrity of the
>> database (so long as the code is well-maintained), so the harm in
>> converting those methods (which are probably the single most  
>> performance
>> important aspect of Potlatch?) to SQL is relatively low, so far as I  
>> can
>> tell...
> 
> One of the other reasons for moving to rails was the holy grail of  
> using postgres, and rails is theoretically db independent. Of course  
> it didn't work out that way.

Main problem here is the lack of good 'GIS' in other databases. It looks like 
I may be forced to move the gis data to a postgres database despite the fact 
that I have had all other systems running Firebird/Interbase for 15 years :(

> On the specific point, I'm all for more speedy SQL on things like that  
> so long as there is a rails logic way too - in much the same way as  
> there apparently is with the tileid stuff. Then if things change  
> significantly (like, say with changesets, rollback, spatial data  
> types) we don't have limited options.

Rails may be nice for some, but for those of us how are coding other 
applications daily without any reference to rails it is a turn off. I do not 
have the time to bother even looking which is a reason that I have not been 
able to contribute on that side. I work with raw data via SQL and will 
continue that way with 25 years of C++ applications and now increasingly PHP. 
So any extensions I come up with ( such as NLPG data interface ) will be in PHP 
:)

-- 
Lester Caine - G8HFL
-
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
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] zoom yahoo data in potlatch?

[Christopher Schmidt]

On Fri, May 02, 2008 at 08:19:52PM -0700, David Muir Sharnoff wrote:
> You're right: that OAM imagery is very detailed.   Unfortunately, it's
> not that good where I'm mapping.  

Sorry, my comments were tongue in cheek. I don't expect there to be many
cases where OAM is the best choice for mapping. 

> Richard, can you add the please?

Richard is likely limited by the Yahoo! Flash API: I expect that there's
a fair chance that Yahoo! hasn't updated their Flash API to provide the
new zoom levels that the main API added 2-3 weeks ago (Yahoo added more
zoom levels worldwide at that time).

(Of course, Richard will tell me if I'm wrong, I'm sure :)) 

Regards,
-- 
Christopher Schmidt
MetaCarta

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

Re: [OSM-talk] zoom yahoo data in potlatch?

[Karl Newman]

On Fri, May 2, 2008 at 8:19 PM, David Muir Sharnoff <[EMAIL PROTECTED]>
wrote:

> You're right: that OAM imagery is very detailed.   Unfortunately, it's not
> that
> good where I'm mapping.   In Oakland, California, Yahoo! has two zoom
> levels beyond what Potlatch will display.   It would be very helpful to me
> if
> Potlatch would display those zoom levels.   Google has one (or two) more
> beyond Yahoo!
>
> Richard, can you add the please?
>
> -Dave
>

Umm... Did you zoom out? That photo is in Alameda. Granted, outside the
boundaries of the Naval Air Station the resolution's not that great. But if
you want to map where to fly model airplanes, you're all set. :-)

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

Re: [OSM-talk] zoom yahoo data in potlatch?

[David Muir Sharnoff]

You're right: that OAM imagery is very detailed.   Unfortunately, it's not that
good where I'm mapping.   In Oakland, California, Yahoo! has two zoom
levels beyond what Potlatch will display.   It would be very helpful to me if
Potlatch would display those zoom levels.   Google has one (or two) more
beyond Yahoo!

Richard, can you add the please?

-Dave

On Fri, May 2, 2008 at 7:40 PM, Christopher Schmidt
<[EMAIL PROTECTED]> wrote:
> On Sat, May 03, 2008 at 12:51:43PM +1200, Robin Paulson wrote:
>  > 2008/5/3 micha ruh <[EMAIL PROTECTED]>:
>  > > in options, choose 'Aerial - OpenAerialMap' as background and you'll be 
> fine
>  >
>  > hmm, i'm slightly baffled by that. the oam coverage for nz is
>  > appalling at best and as an aside, i'd be very surprised if it was
>  > better resolution than the yahoo imagery anywhere on the planet
>
>  In the majority of the world, OAM and Yahoo! imagery are the same --
>  both based on Landsat. The difference, in those areas, is that OAM will
>  display tiles far above "1:1" ratio, as opposed to just giving a 'no
>  data' message.
>
>  Additionally, I highly doubt you will see anything higher resolution
>  than
>  http://openaerialmap.org/map/?lat=37.79202&lon=-122.32715&zoom=21&layers=BF
>  in Yahoo! anywhere on the planet.
>
>  Regards,
>  --
>  Christopher Schmidt
>  MetaCarta
>
>
>
>  ___
>  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] zoom yahoo data in potlatch?

[Christopher Schmidt]

On Sat, May 03, 2008 at 12:51:43PM +1200, Robin Paulson wrote:
> 2008/5/3 micha ruh <[EMAIL PROTECTED]>:
> > in options, choose 'Aerial - OpenAerialMap' as background and you'll be fine
> 
> hmm, i'm slightly baffled by that. the oam coverage for nz is
> appalling at best and as an aside, i'd be very surprised if it was
> better resolution than the yahoo imagery anywhere on the planet

In the majority of the world, OAM and Yahoo! imagery are the same --
both based on Landsat. The difference, in those areas, is that OAM will
display tiles far above "1:1" ratio, as opposed to just giving a 'no
data' message.

Additionally, I highly doubt you will see anything higher resolution
than
http://openaerialmap.org/map/?lat=37.79202&lon=-122.32715&zoom=21&layers=BF
in Yahoo! anywhere on the planet.

Regards,
-- 
Christopher Schmidt
MetaCarta

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

Re: [OSM-talk] Users whose contributions are in the public domain

[Bruce Cowan]

On Fri, 2008-05-02 at 17:01 +0100, Andy Allan wrote:
> And where all the data entered by the PD guys was done without looking
> at the non-PD stuff as a reference? Like a "PD" pub which was
> positioned at the corner of two CC-BY-SA streets, whose coordinates,
> therefore is (arguably) non-PD? Or "PD" rivers that went down the
> middle of a CC-BY-SA cycle-map-contours-background-in-potlatch valley?

The sooner we're united behind one licence the better. Otherwise things
will just be like the Tories not wanting to say what they'd do better.

Politics thrown in for a laugh.
-- 
Bruce Cowan <[EMAIL PROTECTED]>


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

Re: [OSM-talk] zoom yahoo data in potlatch?

[Andrew MacKinnon]

On Fri, May 2, 2008 at 8:51 PM, Robin Paulson <[EMAIL PROTECTED]> wrote:
> 2008/5/3 micha ruh <[EMAIL PROTECTED]>:
>> in options, choose 'Aerial - OpenAerialMap' as background and you'll be fine
>
> hmm, i'm slightly baffled by that. the oam coverage for nz is
> appalling at best and as an aside, i'd be very surprised if it was
> better resolution than the yahoo imagery anywhere on the planet

You'd be better off using a screen magnifier application to zoom the
entire screen. On Windows, Mac and some distributions of Linux they
are built in. On Windows, use the built-in screen magnifier in
Programs > Accessories > Accessibility > Magnifier (instructions:
http://www.microsoft.com/windowsxp/using/accessibility/magnifierturnon.mspx)
On Mac, simply use Ctrl-scroll wheel up to zoom in (you might have to
enable a preference under the "Trackpad" tab of "Keyboard & Mouse
Preferences" to enable it). In Linux, use "Orca" in GNOME or
"KMagnifier" in KDE (your distribution probably has a way to enable
this through "Accessibility Preferences"). I have a Mac, and I do this
all the time to make tracing Yahoo imagery more accurate.

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

Re: [OSM-talk] OSM in Europe Statistics

[Bruce Cowan]

On Wed, 2008-04-30 at 01:45 +0200, Frederik Ramm wrote:
> Hi,
> 
>a very crude statistic:

> I suspect that disregarding the coastline (which is included in my
> figures) would probably cost the Scandinavian countries a few ranks in
> this league. Coastline factor doesn't affect larger countries that much
> (but still strange that Italy should have so little - must investigate
> quality of border polygon).

I realise I'm a bit late replying, but apparently Argyll and Bute
council alone has more coastline than the all of France.

Pointless facts, but that's a Scot for you.
-- 
Bruce Cowan <[EMAIL PROTECTED]>


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

Re: [OSM-talk] zoom yahoo data in potlatch?

[Robin Paulson]

2008/5/3 micha ruh <[EMAIL PROTECTED]>:
> in options, choose 'Aerial - OpenAerialMap' as background and you'll be fine

hmm, i'm slightly baffled by that. the oam coverage for nz is
appalling at best and as an aside, i'd be very surprised if it was
better resolution than the yahoo imagery anywhere on the planet

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

Re: [OSM-talk] zoom yahoo data in potlatch?

[micha ruh]

in options, choose 'Aerial - OpenAerialMap' as background and you'll be fine

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

[OSM-talk] zoom yahoo data in potlatch?

[robin paulson]

i'm doing some work in potlatch (tracing buildings) that needs high zoom 
to be able to trace the building edges.

so, to richard: is there anyway to zoom the yahoo data, rather than it 
disappearing at high zooms? i realise it'll be somewhat pixellated, but 
it's still better than nothing

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

Re: [OSM-talk] Wide tracks with cycle access

[Ari Torhamo]

pe, 2008-05-02 kello 11:07 +0100, Dave Stubbs kirjoitti:


> The main problem with this kind of idea is it's complete subjectivity.
> The bike_suitability style of tag is less of a problem because there's
> a fairly clear reference point: ie: would you be happy cycling a road
> bike down this path, or would the path break it (or you)? So while
> subjective, people will generally be working from a similar baseline.

> But when you start applying -2..+2 grading, you need to calibrate
> everyone's expectations of what that actually means somehow. How do I
> know this is a +2 instead of a +1? Inevitably what this entails is
> writing some kind of guide where you detail all the things you should
> look at to determine the score. By the time you've done this you've
> probably come up with a reasonable surface tagging scheme you could
> have actually used in the first place :-)
> It might be something you could then apply to a map rendering to
> indicate how good a route is without providing the fine detail.

I see that I left out from my idea the essential part that grading would
be used only in addition to tags for track type and surface material,
and only in those cases, when regular tagging, while properly done,
would give a wrong picture of the reality "in the field". I understand
the problem with subjectivity, and of course, if people come up with a
regular tagging scheme that is "objective" and works, then there would
be no need for grading. I could imagine, though, that if this objective
tagging scheme fails to give people the tools they need to describe the
situation in the field, the scheme would be often bent to fit the
reality, and this way, in effect, being also used as a grading tool.

I think bike_suitability would bring new levels of subjectivity to the
mix. At least in my country some half of the bicycles in use are neither
road bikes, hybrids or mountain bikes. There's no clear category these
other bikes belong to, and for example their tyre diameter varies
greatly - an important aspect affecting driveability. You would need
either more categories (they would be fuzzy), or artificially squeeze
the rest of the bikes to existing categories (fuzzy and subjective).
Also, how comfortable the imagined driver would feel riding a certain
type of bike on the track in question? What kind of driver - an 18 years
old? 30? 50? Fit or not-so-fit? Experienced biker or not? A young, fit
driver might feel OK to ride on most tracks with anything except a road
bike. Some one else might feel very differently. So, bike_suitability
seems to me to be even more subjective than surface grading.
Categorizing tracks for bike types partly works, but is to large part
arbitrary. When doing so, you can't avoid categorizing drivers (whether
or not you do it knowingly), which is very subjective - even more so
than grading a track surface.

Anyway, it seems to me that what ever is going to be done, there's going
to be subjectivity involved :-)

Regards,

Ari Torhamo



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

Re: [OSM-talk] Background-only on potlatch?

[Ben Laenen]

On Friday 02 May 2008, Richard Fairhurst wrote:
> OJ W wrote:
> > Is there a way to turn off map data on potlatch, for when you want
> > to zoom-out and look at something on the satellite photos, but
> > don't want to trouble OSM with downloading an entire town's data
> > that you're not planning to use?
>
> There's a request I've not heard before!
>
> Not easily. I suppose the easiest way right now would be to save
> edit.html, potlatch.swf and any required JS/CSS to your hard drive,
> and open that. If you don't have an OSM install running, it will try
> to connect to "your local database" and fail, thereby just leaving
> you with the imagery.

I think he wanted a way to temporarily turn off the map data, so to be 
able to turn it on again when he zoomed back in to a new area to start 
mapping there, so that solution won't help I guess... (it's also 
something I've been wondering about when I was panning across a city 
which took a while rendering the map data every time I moved around)

Right now you have to switch to the "view" page, zoom out, move around, 
zoom in again and switch back to "edit", but I guess the "view" part 
doesn't work when the area isn't mapped or rendered yet for example, so 
you have to either guess the new working location, or do a lot of 
panning in Potlatch.

Greetings
Ben

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

Re: [OSM-talk] [OSM-dev] The future of Potlatch

[Mikel Maron]

From: Tom Hughes <[EMAIL PROTECTED]>


> In part it's an entirely selfish attitude in as much as that Adobe
> show no signs of wanting to support flash on 64 bit linux which means
> that I am left having to rely on the free players or struggling to
> use the 32 bit flash plugin via a kludgy wrapper that barely works
> at the best of times.

Adobe has dropped the licensing restrictions on building competing flash 
players, and will be publishing the spec.

http://blog.wired.com/monkeybites/2008/04/adobe-drops-lic.html

So no open source solution yet for Flash 9, but there's no legal impediments 
any longer.

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

Re: [OSM-talk] WTF ! (about gps traces)

[Karl Newman]

On Fri, May 2, 2008 at 12:12 PM, <[EMAIL PROTECTED]> wrote:

> > Hi there,
> >
> > hey dude, what's that
> > http://openstreetmap.org/user/wwwFrank/traces/104165??
> >
> > --
> > Steven Le Roux
> > Jabber-ID : [EMAIL PROTECTED]
>
> I think that this is a load of waypoints turned into a track.
>
> This type track makes an area unworkable when made public. The mess of gps
> tracks conceals the more 'sensible' tracks, and thus should be strongly
> discouraged from being uploaded (and make public).
>
> Go to:
>
> http://openstreetmap.org/edit?lat=52.2911315395146&lon=8.54396750234422&zoom=14
> in potlatch and press 'g'
>
> Is there any way to prevent particular GPS tracks being displayed in
> potlatch? I know you can limit to your own with 'G' or edit just 1
> specific track, but is there something in between all and one?
>
> Once made 'permanently public', can the user/admins remove a track?
> Simon.
>

Or maybe the tracks need a moderation/voting system. If the tracks are voted
down below a certain threshold, they won't be downloaded? Would need some
careful thought to prevent malicious voting down of good tracks, though.
Even if the editors had a way to hide certain tracks, that would be helpful.
I've seen a few low-quality tracks in my area that I would like to make go
away.

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

Re: [OSM-talk] WTF ! (about gps traces)

[simon]

> Hi there,
>
> hey dude, what's that
> http://openstreetmap.org/user/wwwFrank/traces/104165??
>
> --
> Steven Le Roux
> Jabber-ID : [EMAIL PROTECTED]

I think that this is a load of waypoints turned into a track.

This type track makes an area unworkable when made public. The mess of gps
tracks conceals the more 'sensible' tracks, and thus should be strongly
discouraged from being uploaded (and make public).

Go to:
http://openstreetmap.org/edit?lat=52.2911315395146&lon=8.54396750234422&zoom=14
in potlatch and press 'g'

Is there any way to prevent particular GPS tracks being displayed in
potlatch? I know you can limit to your own with 'G' or edit just 1
specific track, but is there something in between all and one?

Once made 'permanently public', can the user/admins remove a track?
Simon.


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

Re: [OSM-talk] Background-only on potlatch?

[Andrew MacKinnon]

On Fri, May 2, 2008 at 1:14 PM, OJ W <[EMAIL PROTECTED]> wrote:
> Is there a way to turn off map data on potlatch, for when you want to
> zoom-out and look at something on the satellite photos, but don't want
> to trouble OSM with downloading an entire town's data that you're not
> planning to use?

Just go to maps.yahoo.com and click the satellite layer (don't use the
maps!) That's the data source for the satellite photos on OSM, so feel
free to refer to it.

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

Re: [OSM-talk] Background-only on potlatch?

[Richard Fairhurst]

OJ W wrote:

> Is there a way to turn off map data on potlatch, for when you want to
> zoom-out and look at something on the satellite photos, but don't want
> to trouble OSM with downloading an entire town's data that you're not
> planning to use?

There's a request I've not heard before!

Not easily. I suppose the easiest way right now would be to save  
edit.html, potlatch.swf and any required JS/CSS to your hard drive,  
and open that. If you don't have an OSM install running, it will try  
to connect to "your local database" and fail, thereby just leaving  
you with the imagery.

cheers
Richard

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

[OSM-talk] Background-only on potlatch?

[OJ W]

Is there a way to turn off map data on potlatch, for when you want to
zoom-out and look at something on the satellite photos, but don't want
to trouble OSM with downloading an entire town's data that you're not
planning to use?

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

Re: [OSM-talk] Hi-vis vest with OpenStreetMap Logo & "Surveyor" Text

[Graham Smith]

Andy Robinson (blackadder) wrote:

Graham Smith
  

Sent: 02 May 2008 4:50 PM
To: talk@openstreetmap.org
Subject: [OSM-talk] Hi-vis vest with OpenStreetMap Logo & "Surveyor" Text

Hi folks,

I'm in the process of getting a custom high-visibility safety vest
printed for myself, for OSM surveying work, as I do most of my surveying
on-foot and sometimes find myself near busy roads, etc.  



I had the same request out to the mailing list a couple of months ago and
got quite a big response from various around the world. I just haven't had
time to co-ordinate getting a batch printed up. Would be keen to share the
workload if you are interested in doing something on this. The original
thread is at:

http://lists.openstreetmap.org/pipermail/talk/2008-February/023770.html

Cheers

Andy
  
Sorry Andy, I didn't realise you had already kicked something off in 
this respect!


I'll see what the response is like for the design I've put forward.  I 
might not have any choice but to share the workload depending on how 
things go! :) :)  I take it you're based in the UK too?


Cheers,
Graham



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

Re: [OSM-talk] Users whose contributions are in the public domain

[Andy Allan]

On Wed, Apr 30, 2008 at 9:38 PM, Frederik Ramm <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
>  >While I have the PD-user template on my user page and would encourage
>  >like-minded folks to do the same, I feel it is mostly a political
>  >statement  than of real practical benefit.
>
>  +1
>
>  Some time in the far future I will create a "clean" mirror of OSM that
>  contains only data never touched by people who don't do PD.

And where all the data entered by the PD guys was done without looking
at the non-PD stuff as a reference? Like a "PD" pub which was
positioned at the corner of two CC-BY-SA streets, whose coordinates,
therefore is (arguably) non-PD? Or "PD" rivers that went down the
middle of a CC-BY-SA cycle-map-contours-background-in-potlatch valley?

Good luck with that :-P

Cheers,
Andy

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

Re: [OSM-talk] [OSM-dev] The future of Potlatch

[Dave Stubbs]

> -- AS1 / AS3
>
> Dave - I think your definition of donkey balls might be different to
> mine. ;) Or rather, when you've been sucking horse balls for several
> years then donkey balls don't seem very different.
>
> Er, I should probably rephrase that.
>

Yeah, I don't think the relative merits of various equine testicles is
really where I want the conversation to go...

>
> To me (coming from a Perl script kiddie background, rather than
> Proper Programming In Java)

You'll be glad to know I have "opinions" on Perl as well :-). I was
once told that it's possible to write a program to generate haikus in
perl, where the program itself is in fact a haiku. I was told this as
if it was a good thing. To me it merely sounds evil. I found
programming actionscript almost as painful as using C again.

Dave

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

Re: [OSM-talk] Hi-vis vest with OpenStreetMap Logo & "Surveyor" Text

[Andy Robinson (blackadder)]

Graham Smith
>Sent: 02 May 2008 4:50 PM
>To: talk@openstreetmap.org
>Subject: [OSM-talk] Hi-vis vest with OpenStreetMap Logo & "Surveyor" Text
>
>Hi folks,
>
>I'm in the process of getting a custom high-visibility safety vest
>printed for myself, for OSM surveying work, as I do most of my surveying
>on-foot and sometimes find myself near busy roads, etc.  

I had the same request out to the mailing list a couple of months ago and
got quite a big response from various around the world. I just haven't had
time to co-ordinate getting a batch printed up. Would be keen to share the
workload if you are interested in doing something on this. The original
thread is at:

http://lists.openstreetmap.org/pipermail/talk/2008-February/023770.html

Cheers

Andy


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

[OSM-talk] Hi-vis vest with OpenStreetMap Logo & "Surveyor" Text

[Graham Smith]

Hi folks,

I'm in the process of getting a custom high-visibility safety vest 
printed for myself, for OSM surveying work, as I do most of my surveying 
on-foot and sometimes find myself near busy roads, etc.  It's also a 
great way to raise the profile of OSM, whilst offering a real health and 
safety advantage for both pedestrian and bike surveyors.  These 
high-visibility orange vests can be warn over the top of your normal 
clothing, so are suitable for all types of weather conditions.  If 
you're wondering what these vests are, see the following link (you've no 
doubt seen highway maintenance crews, or airport ground crews wearing 
these):

http://www.worksafedepot.co.uk/img/prod_img/hivis/vest.jpg

I'm wondering if anybody else might be interested in purchasing one of 
these with a custom OSM print on the back? I'm trying to gauge the level 
of interest before I think about submitting a bulk order for printing.  
The following are URLs to jpegs of a mock-up of the design I've come up 
with (showing the back of the vest), based on the OSM logo:

http://www.sonicresolutions.com/osm_vest/mockup.jpg
http://www.sonicresolutions.com/osm_vest/mockup2.jpg

Depending on numbers, the vests are likely to sell for around £9.00 each 
+ P&P (P&P will probably be a few pounds for the UK, maybe more to 
Europe/rest of world).  I will donate any profit made after covering my 
expenses, back to OSM.  The price is likely to come down if I can get 
sufficient numbers of interested purchasers to reach price-break points 
for printing.

If you are interested in purchasing one of these printed hi-vis vests, 
could you please e-mail me at "osm at sonicresolutions.com" and include 
"Vest" in the subject line.  In your e-mail, please state the size and 
quantity of vests you would be interested in purchasing, and your 
country if you're outside the UK (so I can get together accurate postage 
costs). Available sizes are:

Small 33-38
Medium 38-41
Large 41-44
X Large 44-47
XX Large 47-50
XXX Large 50-54
 Large 54-56

At this stage I'm just trying to gauge interest and your e-mail to me 
will of course *not* commit you to purchase.  Once I've got a list of 
interested parties, if the numbers are sufficient, I'll e-mail everyone 
individually with the final costings and payment will probably be via 
PayPal.  I won't call for payment until I've actually got the vests in 
front of me, ready to dispatch.

Any questions, please feel free to drop me an e-mail.

Kind regards,
Graham Smith



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

Re: [OSM-talk] [OSM-dev] The future of Potlatch

[Richard Fairhurst]

Thanks for some really helpful and interesting responses. (Thanks  
especially to Tom C for a very valuable perspective.)


-- API

The API has come up a lot. I've said before and will happily restate  
now that I think it would be great to get Potlatch talking Rails on  
the serverside, rather than the SQL at present. It wouldn't affect  
the Potlatch user experience (which is my primary concern), but would  
mean more peace-of-mind for Tom H, Steve et al; its benefits could be  
open to other editors; and it'd remove a major stumbling block when  
talking about Potlatch, which would be helpful.

I don't have any emotional attachment to the code there at the moment  
- it's simply like that because it was actually developed before OSM  
moved to Rails (the pre-Rails API was a lot less sophisticated than  
the current one and really couldn't do what Potlatch needed), and  
rewriting it in Rails is something I'm not really qualified to do  
safely without breaking lots of stuff. One can always learn, and  
given unlimited time I'd like to; but sadly I don't currently have  
the time to learn AS3, _and_ Rails, _and_ respond to people's  
requests for Potlatch... oh, and do the day job! So given that the  
serverside code works, albeit inelegantly, learning to rewrite it  
hasn't been my priority.

I'm very happy, of course, to spend as much time as necessary talking  
others through how it currently works should they be kind enough to  
take on the task of rewriting it - I've already documented a bunch of  
it for Steve. I'm pretty sure that'd be more efficient than me  
blundering in and writing some very bad Rails code.

There are really only two provisos to this and neither's a big one, I  
think. I do feel fairly strongly that Potlatch, as currently written,  
and the API should continue to talk AMF to each other rather than  
XML; it keeps the code compact and fast, especially given that AS1  
doesn't have great XML handling. But that's just a transport format,  
really, just 50 or so lines of (pretty reliable and fast) code.

The other one is that it would be good if the getway call, in  
particular, could exist in _both_ SQL and Rails forms in the code,  
with a switch called RICHARD_NOT_HIT_BY_BUS_YET to determine which  
one is called. Up until the time of the bus incident we could use the  
(very, very simple, read-only) single SQL call because it's between  
two and four times faster, and this is the one call that does have a  
significant performance impact on Potlatch. After I'm run over, you  
could switch to Rails, which means a performance hit but may be  
considered more maintainable. Please don't treat this as an  
invitation to drive a bus at me.

Pretty much everything I'd want to say on this has already been  
expressed by TomH:
http://lists.openstreetmap.org/pipermail/talk/2008-May/025886.html
http://lists.openstreetmap.org/pipermail/talk/2008-May/025889.html


-- Frederik's uniqueness point

Really can't argue with that. Going back to the Java applet days I  
did actually want both it and Potlatch to be available at the same  
time (http://wiki.openstreetmap.org/index.php/ 
Talk:Java_Applet_Development); unfortunately this never happened. But  
as long as the choice is presented through a friendly UI and doesn't  
confuse novices, it's a good principle.

On the openness (or otherwise) of Potlatch, Frederik, I think I  
mentioned to you in the internationalisation discussion that I'm  
planning to build a preset tagging system that will let people  
contribute their own plug-in tagging panels. Otherwise Potlatch's  
only impact on mapping practices has probably been to hasten the  
demise of segments which I suspect you agreed with!


-- AS1 / AS3

Dave - I think your definition of donkey balls might be different to  
mine. ;) Or rather, when you've been sucking horse balls for several  
years then donkey balls don't seem very different.

Er, I should probably rephrase that.

To me (coming from a Perl script kiddie background, rather than  
Proper Programming In Java) AS1 is the nice approachable stuff while  
AS3 is scary with lots of stuff you have to write that doesn't  
actually do anything. I'm not holding that up as a truth, I don't  
doubt that AS3's objectively the better language by current norms:  
it's just that it's an utterly new way of doing things for me, and I  
can't immediately see the payback for me in spending a long while  
learning it, then rewriting all 7,000 lines of code. AS3 doesn't yet  
_do_ much that AS1 doesn't: some clever typography stuff (not needed  
for Potlatch), faster (but Potlatch's UI is plenty fast, it's the  
server responses that slow the UI), and better XML handling (but as  
written Potlatch doesn't need that). And it doesn't make me more  
marketable as a programmer because I'm not a professional programmer.

Now this is my problem, of course, not something anyone else needs to  
worry about. But it's the thing that I'm still most unsure how

Re: [OSM-talk] WTF ! (about gps traces)

[Doru-Julian Bugariu]

Steven Le Roux schrieb:

Hi there,

hey dude, what's that  
http://openstreetmap.org/user/wwwFrank/traces/104165 ??


Download data, rename it to blah.gpx and load it into JOSM. Looks OK to 
me. Probably more than one gpx track combined.


Taking a look at the OSM data with JOSM in that area, I can see there 
are plenty of ways not properly connected. But taking into account that 
the upload date is 2005-05-02 (today!) it looks for me like normal "work 
in progress".


As I am writing, Osmarender is updating the area.

Regards,
Julian



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] WTF ! (about gps traces)

[wiseLYNX]

way funny.. and, having a look at the map already done there, it seems
that there's a lot of POIs without a reason to be there..

Enrico Manzini

Steven Le Roux wrote:
> Hi there,
> 
> hey dude, what's that 
> http://openstreetmap.org/user/wwwFrank/traces/104165 ??
> 
> -- 
> Steven Le Roux
> Jabber-ID : [EMAIL PROTECTED] 
> 
> 
> 
> 
> ___
> 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] WTF ! (about gps traces)

[Lauri Hahne]

That's propably the trace viewer sucking horribly. If you look at his other
traces, you can see that he has got other traces like that which are
apparently exported from a gis system.

2008/5/2 Steven Le Roux <[EMAIL PROTECTED]>:

> Hi there,
>
> hey dude, what's that
> http://openstreetmap.org/user/wwwFrank/traces/104165 ??
>
> --
> Steven Le Roux
> Jabber-ID : [EMAIL PROTECTED]
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>
>


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

Re: [OSM-talk] WTF ! (about gps traces)

[Andy Allan]

When you try editing it, you can see the intersections of the GPS
lines match points along the ways. I suspect that the nodes are a
valid trace with bogus timestamps, so the points on the trace are
out-of-order, and it looks a mess when you join them.

Other explanations are of course possible!

Cheers,
Andy

On Fri, May 2, 2008 at 2:27 PM, Steven Le Roux <[EMAIL PROTECTED]> wrote:
> Hi there,
>
> hey dude, what's that  http://openstreetmap.org/user/wwwFrank/traces/104165
> ??
>
> --
> Steven Le Roux
> Jabber-ID : [EMAIL PROTECTED]
> ___
>  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] WTF ! (about gps traces)

[Steven Le Roux]

Hi there,

hey dude, what's that  http://openstreetmap.org/user/wwwFrank/traces/104165??

-- 
Steven Le Roux
Jabber-ID : [EMAIL PROTECTED]
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] [OSM-dev] The future of Potlatch

[SteveC]

On 2 May 2008, at 12:38, Christopher Schmidt wrote:
> Some things don't require referential integreity: selecting ways/nodes
> within a bounding box can't hurt the referential integrity of the
> database (so long as the code is well-maintained), so the harm in
> converting those methods (which are probably the single most  
> performance
> important aspect of Potlatch?) to SQL is relatively low, so far as I  
> can
> tell...

One of the other reasons for moving to rails was the holy grail of  
using postgres, and rails is theoretically db independent. Of course  
it didn't work out that way.

On the specific point, I'm all for more speedy SQL on things like that  
so long as there is a rails logic way too - in much the same way as  
there apparently is with the tileid stuff. Then if things change  
significantly (like, say with changesets, rollback, spatial data  
types) we don't have limited options.

Best

Steve


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

Re: [OSM-talk] New Potlatch

[Andy Robinson (blackadder)]

[EMAIL PROTECTED] wrote:
>Sent: 01 May 2008 11:37 PM
>To: Richard Fairhurst
>Cc: talk@openstreetmap.org
>Subject: Re: [OSM-talk] New Potlatch
>
>> - When you add a point into a way where it crosses another way,
>> Potlatch automatically makes an intersection.
>
>Is this 'feature' able to be turned off? Otherwise I would consider it a
>bug as it means that you can't do bridges over other ways.

Bridges are normally done as a short section of way rather than a node at
the "intersection".

Cheers

Andy

>
>Mungewell.
>
>
>
>___
>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] [OSM-dev] The future of Potlatch

[Christopher Schmidt]

On Fri, May 02, 2008 at 12:27:38PM +0100, Tom Hughes wrote:
> > I won't pretend that I know nearly as much about the rails code as you
> > do, but it seems like some of these would be better abstracted out. If
> > that were the case -- that is, that all the Rails code on the site used
> > the same underlying methods to talk to the database, given a 'fixed'
> > API, and amf_controller was just about encoding the returned data into
> > AMF -- then I thiink it would be possible to change the underlying slow
> > methods into SQL (after proper profiling), because the main reason not
> > to is 'maintaining two different codebases sucks', rather than 'no one
> > likes SQL over rails'.
> 
> If I thought Steve would let me get away with doing raw SQL instead
> of using the rails object model I might have done so long ago ;-)
> 
> Doing so would bypass all the integrity checks though, which is
> bad - that's a side effect of having the integrity checks in the
> wrong place (the rails object model rather than the database).

Some things don't require referential integreity: selecting ways/nodes
within a bounding box can't hurt the referential integrity of the
database (so long as the code is well-maintained), so the harm in
converting those methods (which are probably the single most performance
important aspect of Potlatch?) to SQL is relatively low, so far as I can
tell...

Regards,
-- 
Christopher Schmidt
MetaCarta

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

Re: [OSM-talk] [OSM-dev] The future of Potlatch

[SteveC]

Richard

I'm sorry you think informal private chats are now in the public  
domain, I'll keep it in mind.

All

This is not quite what happened.

For a start, this doesn't really have anything to do with CloudMade,  
it started a long time before that. It's about the maintainability and  
quality of potlatch.

Some time ago when Nick and I decided to spend a week of our company  
time (as a consultancy as it was then, it was a strain on our time) I  
discovered how bad Richards API was. As a bit of background, there is  
the main API and Richard doesn't want to write against it so he wrote  
an entire Flash API in the Rails server which doesn't reuse any code,  
doesn't use any of the object models, writes raw SQL and is basically  
flawed.

I, and any sane coder, thinks Potlatch should be using the main API. I  
thought I'd do what I know quite  a bit about - the rails backend. I  
found it quite difficult to improve any of it and after a week I think  
I'd improved one or two things but not made much headway. Richard felt  
pretty personal about it and left IRC a few times.

After that I tried to get other people interested in solving it,  
either the backend or potlatch itself. I found it very difficult to  
get anyone interested in the rails bit which is why I used to do all  
that boring stuff in the first place. As for the frontend, there was a  
fair amount of interest in hacking it until those I spoke to found out  
it is in an ancient version of ActionScript, doesn't use the API and  
requires a pile of bizarre libraries to compile it.

Faced with not being able to interest anyone in the problems, I tried  
to solve them with Richard.

I, personally, and with company funds offered basically everything I  
can think of under the sun to get him to let go of the stranglehold on  
the codebase and help others contribute to it. I offered to buy a copy  
of the latest flash compiler suit, whatever it is called. I offered to  
buy the books. I personally offered to ship him the rails books to  
learn how to write good backend code. I offered to send him on a  
course (so I'm disappointed how he's phrased wanting to now get a  
grant, as if this was never talked about). I offered to let him manage  
paid coders to improve it. I even offered to fly him out to california  
and meet people (there seem to be lots of good flash and interaction  
designers out there).

Basically, Richard said no to all of it.

All of this is just to improve potlatch (which most people I've spoken  
to think should be a complete rewrite). I tried very hard. Forgetting  
about all of that for a second - think about what happens if Richard  
loses interest or gets run over by a bus. Basically we're screwed as  
nobody else knows how to code against it. That's not true of the rails  
port - and the rails port was done for exactly that reason and has  
been moderately successful. If I or Tom get run over by busses, all is  
not lost.

Faced with him being so stubborn, I talked to more people about what  
to do and figured that meeting in person might be helpful. So I  
travelled up to north of birmingham in my own time, bought the food  
and tried all of the above points. Andy Robinson came along as well. I  
got nowhere, Richard still feels aggrieved and stubborn.

On a more positive note, all I'm trying to do is get more people  
coding potlatch and hence make it better. I'm also trying to get it to  
use a clean API. Potlatch is great, it's improved way beyond the  
applets that tom and I wrote, but it needs to get better. I've tried  
pretty hard every way I can think and the roadblock is Richard.

We've now reached the point where Richard has rebuffed all offers of  
help, doesn't see the issues and wants to appeal to the community for  
support by taking private conversations public without warning and  
misrepresenting what I've been trying to do.

So I'm open to any advice on what to do next.





On 1 May 2008, at 18:35, Richard Fairhurst wrote:

> [warning - long ponderous e-mail follows!]
>
> Hi all,
>
> A fairly weighty issue concerning the future of Potlatch has arisen,
> and I'm completely baffled as to what to do - so I thought I'd "ask  
> the
> community" for thoughts and advice.
>
> CloudMade (Steve and Nick's VC-funded company set up to commercialise
> OSM data, www.cloudmade.com) wants to commission a new online Flash
> editor for OSM. It would, I believe, probably be written by developers
> from Stamen Design (www.stamen.com): some of you will remember that
> Stamen's Tom Carden wrote OSM's early Java editing applet, and they've
> also written a slippy map in Flash called Modest Maps.
>
> As you can imagine, this has taken me aback a bit.
>
> As I understand it, their main issue is a technical one. Potlatch is
> written in ActionScript 1, which is the same language as JavaScript,
> but for Flash. The latest version is ActionScript 3, which is much  
> more
> like Java for Flash. The end user doesn't notice a dif

Re: [OSM-talk] [OSM-dev] The future of Potlatch

[Tom Hughes]

In message <[EMAIL PROTECTED]>
Christopher Schmidt <[EMAIL PROTECTED]> wrote:

> On Fri, May 02, 2008 at 08:35:06AM +0100, Tom Hughes wrote:
>> To summarise I think we both want the same thing, but you perhaps
>> think somebody should just sit down and bang an AMF version of the
>> current XML API and I'm happy with trying to incrementally move
>> towards that position?
>
> Well, I don't think that's how I would put it. I think you were slightly
> oversimplifying when you just said "It's a few lines of Rails object
> code." Some of the request methods in Potlatch are at least a bit more
> complex than that. getway_old, for example, is slightly more complex
> than that, as is putway.

Neither of those methods has been converted to using rails yet - they
are both still using raw SQL to do the work.

Methods which have been converted are things like whichways and getpoi.

> I won't pretend that I know nearly as much about the rails code as you
> do, but it seems like some of these would be better abstracted out. If
> that were the case -- that is, that all the Rails code on the site used
> the same underlying methods to talk to the database, given a 'fixed'
> API, and amf_controller was just about encoding the returned data into
> AMF -- then I thiink it would be possible to change the underlying slow
> methods into SQL (after proper profiling), because the main reason not
> to is 'maintaining two different codebases sucks', rather than 'no one
> likes SQL over rails'.

If I thought Steve would let me get away with doing raw SQL instead
of using the rails object model I might have done so long ago ;-)

Doing so would bypass all the integrity checks though, which is
bad - that's a side effect of having the integrity checks in the
wrong place (the rails object model rather than the database).

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] [OSM-dev] The future of Potlatch

[Christopher Schmidt]

On Fri, May 02, 2008 at 08:35:06AM +0100, Tom Hughes wrote:
> To summarise I think we both want the same thing, but you perhaps
> think somebody should just sit down and bang an AMF version of the
> current XML API and I'm happy with trying to incrementally move
> towards that position?

Well, I don't think that's how I would put it. I think you were slightly
oversimplifying when you just said "It's a few lines of Rails object
code." Some of the request methods in Potlatch are at least a bit more
complex than that. getway_old, for example, is slightly more complex
than that, as is putway.

I won't pretend that I know nearly as much about the rails code as you
do, but it seems like some of these would be better abstracted out. If
that were the case -- that is, that all the Rails code on the site used
the same underlying methods to talk to the database, given a 'fixed'
API, and amf_controller was just about encoding the returned data into
AMF -- then I thiink it would be possible to change the underlying slow
methods into SQL (after proper profiling), because the main reason not
to is 'maintaining two different codebases sucks', rather than 'no one
likes SQL over rails'.

The fact that Potlatch was using SQL was unfortunate, but for 
some problems, that could be the right solution. The fact that the API was
*not* was what I would see as the real problem -- and changing the
architecture so that that wouldn't happen for the same task seems
valuable to me, or at least heading in that direction.

Perhaps you were already heading there; I don't really know what the
plans are for rails_port development, so I'm probably off my rocker :)

Perhaps I'm wrong on this stuff: as I said, I'm new to the rails world.
At this point, putting my code where my mouth is is probably the right
choice, so until I sit down and hack on stuff, it's fine to ignore what
I'm saying :)

I'll see if I get time to have a play this weekend and improve my
knowledge and understanding of the code, and maybe I'll find that you're
right, and there's no reason to bother.

Regards,
-- 
Christopher Schmidt
MetaCarta

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

Re: [OSM-talk] Wide tracks with cycle access

[Dave Stubbs]

On Fri, May 2, 2008 at 1:55 AM, Ari Torhamo <[EMAIL PROTECTED]> wrote:

> pe, 2008-05-02 kello 00:28 +0200, Martin Simon kirjoitti:
> > Am Donnerstag, 1. Mai 2008 13:37:32 schrieb Andy Robinson (blackadder):
>
> > OK, you're totally right at this, it seems difficult to define structure
> of
> > road surfaces - several proposals in the wiki exist, but none seems to
> have
> > seen broad use in actual mapping - in short, I do'nt have a solution.
> > But the need for some reliable, robust and versatile surface tagging
> method
> > seems to be there, as there are ~3 proposals in the wiki to renew/extend
> > surface tags.
> > And I really do think its better to do this now than to re-tag specific
> > vehicle-based tags in the future.
>
> Just an idea: what about having a separate tag for the "driveability" of
> the surface. Even when the surface material is basically the same, the
> driving experience with a bicycle my vary relatively much. The
> driveability tag could be used when driving experience is different from
> what one might expect based on the track type or the surface material of
> the track. For example, grades like -1, -2, or +1 and +2 could be used
> when the driving experience is worse or better than expected.
>

The main problem with this kind of idea is it's complete subjectivity. The
bike_suitability style of tag is less of a problem because there's a fairly
clear reference point: ie: would you be happy cycling a road bike down this
path, or would the path break it (or you)? So while subjective, people will
generally be working from a similar baseline.

But when you start applying -2..+2 grading, you need to calibrate everyone's
expectations of what that actually means somehow. How do I know this is a +2
instead of a +1? Inevitably what this entails is writing some kind of guide
where you detail all the things you should look at to determine the score.
By the time you've done this you've probably come up with a reasonable
surface tagging scheme you could have actually used in the first place :-)
It might be something you could then apply to a map rendering to indicate
how good a route is without providing the fine detail.


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

Re: [OSM-talk] [OSM-dev] The future of Potlatch

[bvh]

On Fri, May 02, 2008 at 10:25:50AM +0100, Dave Stubbs wrote:
> OTH I don't know much about AS3 so I can't say whether it's much better in
> this regard, but from a quick scan of it, I'd say it was. I think the main
> problem is the likely-hood of an opensource player being available for it.
> AS3 means flash 9 and better only, and currently the os stuff is way off
> that. I don't know whether that's likely to change any time soon. There is
> an official adobe 32bit linux version that works very well though, which
> will be good enough for most people.

Just to give a counterweight (because you are the second person
de-emphasizing the free tools argument) : I strongly value that
openstreetmap not only provides 'free' data but also unencumbered
tools to work with that data. Obviously the closer to the hearth
of the project (and potlatch is very close to it), the more so.

> I'd try to be optimistic and keep developing -- raise the bar for any new
> editor as high as you can make it.

While I have no opinion either way on the whole issue brought up in
this thread, I can only agree with this.

cu bart

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

Re: [OSM-talk] [OSM-dev] The future of Potlatch

[Andy Robinson (blackadder)]

Tom Hughes wrote:
>Sent: 02 May 2008 9:51 AM
>To: [EMAIL PROTECTED]; talk@openstreetmap.org
>Subject: Re: [OSM-dev] The future of Potlatch
>
>In message <[EMAIL PROTECTED]>
>Richard Fairhurst <[EMAIL PROTECTED]> wrote:
>
>> For most purposes AS3 probably is a better language - except for the
>> fairly major proviso there's no open-source player even in development.
>
>As far as I'm concerned this is quite a key point, although I know
>that Steve disagrees with me violently on this ;-)
>
>In part it's an entirely selfish attitude in as much as that Adobe
>show no signs of wanting to support flash on 64 bit linux which means
>that I am left having to rely on the free players or struggling to
>use the 32 bit flash plugin via a kludgy wrapper that barely works
>at the best of times.

I believe there is the temptation to think that the project should always
pamper to all of us who have grown up with it thus far, afterall, if it
changed significantly from our prior experience or expectations we would
probably feel more and more left and out and ultimately move on to other
things. I hope that doesn't happen for any of us.

However, we can't avoid the observation that the project continues to grow
exponentially and as it does so, and assuming it continues to do so, the
number of potential contributors and users will probably increasingly come
from non opensource backgrounds. More and more will be wanting to experience
OSM from the standard ibm clone box running the big corporate software
offerings. So, we shouldn't leave our heads in the sand, development on all
fronts should be encouraged, open source or proprietary really doesn't
matter, surely the community will decide what it wishes to use.

The one bit I feel strongly should not be tampered with without widespread
community agreement is what happens at the database end, and that includes
what should and should not be available via the API (or any additional API's
that get suggested). If we want to maintain true openness then we make it
clear what the API can and can't do (we already do this), be responsive to
new ideas for opening up the API and provide every assistance to those
developing tools that use the API. Those tools, whether they are editors,
viewers, routing products, mobile phones or whatever, should in my view be
allowed to develop separately from the core OSM function. This means that if
there are 10 editors out there we really shouldn't favour any particular
one, but make all that comply with the requirements of the API available to
users.

Cheers

Andy


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

Re: [OSM-talk] [OSM-dev] The future of Potlatch

[Dave Stubbs]

On Thu, May 1, 2008 at 6:35 PM, Richard Fairhurst <[EMAIL PROTECTED]>
wrote:

> [warning - long ponderous e-mail follows!]
>
> Hi all,
>
> A fairly weighty issue concerning the future of Potlatch has arisen,
> and I'm completely baffled as to what to do - so I thought I'd "ask the
> community" for thoughts and advice.
>
> CloudMade (Steve and Nick's VC-funded company set up to commercialise
> OSM data, www.cloudmade.com) wants to commission a new online Flash
> editor for OSM. It would, I believe, probably be written by developers
> from Stamen Design (www.stamen.com): some of you will remember that
> Stamen's Tom Carden wrote OSM's early Java editing applet, and they've
> also written a slippy map in Flash called Modest Maps.
>
> As you can imagine, this has taken me aback a bit.
>
> As I understand it, their main issue is a technical one. Potlatch is
> written in ActionScript 1, which is the same language as JavaScript,
> but for Flash. The latest version is ActionScript 3, which is much more
> like Java for Flash. The end user doesn't notice a difference, but the
> programming style is very different.
>
> CloudMade believes this is holding back the development of OSM: that if
> the editor were written in the latest version of the language, more
> Flash designers would come to work on it, resulting in a better editor.
> Steve cites OSM's move from pure Ruby to Ruby on Rails as an example of
> how a contemporary language encourages more people to contribute. And
> they're also worried that if I were run over by a bus then no-one would
> be able to speak ActionScript 1 and maintain Potlatch.
>
> I'm not so sure. I think people are beginning to contribute code to
> Potlatch; that as essentially JavaScript it's approachable enough; and
> that the problems of attracting developers is symptomatic of core OSM
> in general (as per http://trac.openstreetmap.org/log/sites/rails_port).
>
> I hope that Potlatch, as something maintained by an active community
> participant _for_ the community, has demonstrated a pretty rapid rate
> of improvement anyway. It's meant to be small and compact, of course,
> not a a bells-and-whistles editor like JOSM: nonetheless, in the last
> few months, for example: it's become the only editor yet to offer
> revert/history, gained very good relations support, background layers,
> flexible GPX import, etc. And there's a lot of stuff on the way, mostly
> focusing on usability - from a generic 'undo' and pop-up help panel to
> a new, super-user-friendly tagging panel with draggable POI icons and
> things like that. It's got faults, everything has, but it's come a long
> way in the last year. For what it's worth I think it's the best thing
> I've ever coded.
>
> For most purposes AS3 probably is a better language - except for the
> fairly major proviso there's no open-source player even in development.
> Indeed, if I were starting all over again I'd probably do it in AS3,
> and in a couple of years I may well migrate Potlatch to AS3 (or 4, or
> whatever) anyway. But right now it's more important to spend time
> improving usability for mappers, given that - like most people here - I
> do have a full-time job which isn't OSM (which isn't computer-related
> at all, in fact) and consequently time is not unlimited.
>
> So I really don't know what to do.
>
> Part of me thinks that the most important thing is that Potlatch is
> still available and users are offered the choice. Part of me thinks,
> well, if there's going to be a new Flash editor, there's no point in me
> doing any development on Potlatch from today forward. Part of me wants
> to say "well, screw you" and walk away. And part of me wants to take
> CloudMade up on its OSM Grants scheme (http://blog.cloudmade.com/) and
> say, ok then, I'll announce a medium-term feature freeze, take a few
> weeks' holiday, learn AS3 and recode it for a large amount of $$$. I'm
> utterly stumped and would welcome suggestions.
>
> Thanks for reading. :)
>

np :-)

OK, first up potlatch's code:

 - ActionScript 1 in my professional opinion sucks donkey balls
 - how on earth you kept sane while writing Potlatch with that kind of lead
weight I don't know, but Good Job!
 - there are occasions in the code where it could do with some redesign --
there's been lots of improvements along these lines made by yourself in the
lead up to 8 and onwards.
 - having it's own API is a bit of a maintenance nightmare -- IMHO it should
at least use rails models throughout to reduce the impact of this

When it comes to attracting developers there is a problem here: the learning
curve to start coding Potlatch is massive. You have to learn AS1, you have
to learn how flash works in weird ways, you have to learn to avoid Ming bugs
such as using "return" statements in the wrong place. And once you get into
it, you end up going round in circles tearing your hair out because you
missed one of those bugs or quirks. On top of all that you have to learn how
Potlatch itself works (whic

Re: [OSM-talk] [OSM-dev] The future of Potlatch

[Tom Hughes]

In message <[EMAIL PROTECTED]>
Richard Fairhurst <[EMAIL PROTECTED]> wrote:

> For most purposes AS3 probably is a better language - except for the 
> fairly major proviso there's no open-source player even in development. 

As far as I'm concerned this is quite a key point, although I know
that Steve disagrees with me violently on this ;-)

In part it's an entirely selfish attitude in as much as that Adobe
show no signs of wanting to support flash on 64 bit linux which means
that I am left having to rely on the free players or struggling to
use the 32 bit flash plugin via a kludgy wrapper that barely works
at the best of times.

So this isn't, as far as I'm concerned, primarily about some sort of
ideological wish to use a free software solution, which is what Steve
often seems to think this about. It's because the proprietary vendor
has manifestly failed to provide for me, in the way which they often
do because they will always concentrate on majority platforms.

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] help with coastline

[Rob Reid]

Ulf Mehlig wrote the following on 01/05/2008 08:47:
> Hello openstreetmap experts,
>
> I tried to add a few details to a segment of the coastline of northern
> Brazil, but as I see today on Mapnik this caused some disorder in the
> coastline rendering (it looked almost ok in the slippy map/Osmarender,
> though).
>
> I would appreciate if one of the more experienced coastliners could help
> me to find the error(s) -- I'm stuck at the moment!
>
> The area in question is 
>
> http://www.openstreetmap.org/?lat=-0.9293&lon=-46.6796&zoom=12&layers=B0FT
>
> Many thanks in advance (and sorry for the mess ...)
> Ulf
>   
I spotted some of this yesterday on the coastline error checker and 
tried to fix a few bits.
The api seems to be down at the moment so I can't confirm exactly which 
bits I did but the main problem I found was what you had done at river 
mouths.
The main coastline way coming along the coast and across the river mouth 
was ok but the way around the river mouth was tagged as 
natural=coastline as well as waterway=riverbank.
One of the rules with coastline is that they can't fork so the orphan 
bit  of coastline around the mouth is causing problems I think. What I 
did with most of the ones I found was leave the main coastline as it was 
and change the way for the river mouth to be natural=water and make sure 
it was closed. I used this tag as I'm not sure an unclosed riverbank way 
works with all the renderers yet.

Cheers

rcr


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

Re: [OSM-talk] The future of Potlatch

[elvin ibbotson]

Richard,

I use both JOSM and Potlatch. Each has its own strengths and would be  
missed if it were to disappear. Equally, each could (and I'm sure  
will) be improved. I'm not sure what Cloudmade's motivation is. As a  
commercial company are they looking to make money from their new  
editor? Or are they intending to present it to the OSM community as a  
replacement for Potlatch?


On the question of ActionScript: I haven't used it (or Flash) but I  
have done quite a bit of JavaScript and a whole lot of Java  
programming. I don't know what the ActionScript 1 experience is like  
but I find using JavaScript like driving in fog (difficult to know  
where to go or where you went wrong) and would use Java every time.  
If the ActionScript 1/3 relationship is anything like JavaScript/Java  
I would jump ship at the earliest opportunity (and if Steve & Nick  
will give you some of their VC cash to do it, all the better!).


I'm sure you have tremendous respect from OSM people and will have  
plenty of support. I know how I would feel in your place and I know  
from experience that it is likely to look totally different when it  
all settles out. Potlatch works fine for now and from what you say no- 
one has even started coding another Flash editor, so why not take  
some time out as you suggest and let the dust settle. I bet if you  
rebuilt Potlatch from the bottom up, using a better language, it  
would be all that any of us could ask for.


elvin ibbotson




From: Richard Fairhurst <[EMAIL PROTECTED]>
Date: 1 May 2008 18:35:59 BDT
To: talk@openstreetmap.org, [EMAIL PROTECTED]
Subject: [OSM-talk] The future of Potlatch


[warning - long ponderous e-mail follows!]

Hi all,

A fairly weighty issue concerning the future of Potlatch has  
arisen, and I'm completely baffled as to what to do - so I thought  
I'd "ask the community" for thoughts and advice.


CloudMade (Steve and Nick's VC-funded company set up to  
commercialise OSM data, www.cloudmade.com) wants to commission a  
new online Flash editor for OSM. It would, I believe, probably be  
written by developers from Stamen Design (www.stamen.com): some of  
you will remember that Stamen's Tom Carden wrote OSM's early Java  
editing applet, and they've also written a slippy map in Flash  
called Modest Maps.


As you can imagine, this has taken me aback a bit.

As I understand it, their main issue is a technical one. Potlatch  
is written in ActionScript 1, which is the same language as  
JavaScript, but for Flash. The latest version is ActionScript 3,  
which is much more like Java for Flash. The end user doesn't notice  
a difference, but the programming style is very different.


CloudMade believes this is holding back the development of OSM:  
that if the editor were written in the latest version of the  
language, more Flash designers would come to work on it, resulting  
in a better editor. Steve cites OSM's move from pure Ruby to Ruby  
on Rails as an example of how a contemporary language encourages  
more people to contribute. And they're also worried that if I were  
run over by a bus then no-one would be able to speak ActionScript 1  
and maintain Potlatch.


I'm not so sure. I think people are beginning to contribute code to  
Potlatch; that as essentially JavaScript it's approachable enough;  
and that the problems of attracting developers is symptomatic of  
core OSM in general (as per http://trac.openstreetmap.org/log/sites/ 
rails_port).


I hope that Potlatch, as something maintained by an active  
community participant _for_ the community, has demonstrated a  
pretty rapid rate of improvement anyway. It's meant to be small and  
compact, of course, not a a bells-and-whistles editor like JOSM:  
nonetheless, in the last few months, for example: it's become the  
only editor yet to offer revert/history, gained very good relations  
support, background layers, flexible GPX import, etc. And there's a  
lot of stuff on the way, mostly focusing on usability - from a  
generic 'undo' and pop-up help panel to a new, super-user-friendly  
tagging panel with draggable POI icons and things like that. It's  
got faults, everything has, but it's come a long way in the last  
year. For what it's worth I think it's the best thing I've ever coded.


For most purposes AS3 probably is a better language - except for  
the fairly major proviso there's no open-source player even in  
development. Indeed, if I were starting all over again I'd probably  
do it in AS3, and in a couple of years I may well migrate Potlatch  
to AS3 (or 4, or whatever) anyway. But right now it's more  
important to spend time improving usability for mappers, given that  
- like most people here - I do have a full-time job which isn't OSM  
(which isn't computer-related at all, in fact) and consequently  
time is not unlimited.


So I really don't know what to do.

Part of me thinks that the most important thing is that Potlatch is  
still available and users are offered the cho

Re: [OSM-talk] [OSM-dev] The future of Potlatch

[Tom Hughes]

In message <[EMAIL PROTECTED]>
Christopher Schmidt <[EMAIL PROTECTED]> wrote:

2> On Fri, May 02, 2008 at 12:24:35AM +0100, Tom Hughes wrote:
>> In message <[EMAIL PROTECTED]>
>>   "Tom Carden" <[EMAIL PROTECTED]> wrote:
>> 
>> > I think the fact that it has its own API is a much bigger concern than
>> > it being written in AS 1.0 is.  If Potlatch was using the main API,
>> > development of API-backed features in Potlatch could be shared by
>> > other editors too.  Any tests written for the API would help Potlatch.
>> >  Any changes to the schema would only have to happen once. etc. etc.
>> 
>> I think most of us (with the possible exception of Richard) would
>> agree here.
>> 
>> Well actually I don't mind the existence of the AMF API as such so
>> long as it is just concerned with decoding the RPC calls and encoding
>> the results, and it uses the rails object model to do all the work
>> so that important code is shared with the XML API.
>
> There's an important difference between this and "Potlatch using the
> main API".

Well yes, the two are not very well aligned at the moment and
that also needs fixing.

> There are, I believe, some things that Potlatch can do that no
> other client can do, because the API to do it is not available.
>
> Specifically:
>  * whichways_deleted gets deleted ways in a bbox, which the main API
>doesn't provide
>  * getway_old has a "last deleted version", which seems different
>
> More problematic than the specific methods which do or don't exist,
> however, is the fact that the Potlatch way of interacting with them is
> *entirely* different -- so when a bug is fixed in the main API, the fix
> has to be duplicted in the Potlatch/amf_controller.

Which is why we're trying to make as much code as possible common
to both - there's a long way to go, but it's a good target.

The point I would like to reach is one where the only difference is
how arguments are decoded and how results are encoded and everything
in between is the same with the same set of API calls exposed via
both the AMF and XML interfaces.

> This affects development of the server side APIs. You, at one point, put
> forward a significant amount of effort in improving the Rails code in
> amf_controller: that work benefited only Potlatch. If Potlatch was using
> the same backend rails calls (rather than just objects/models), then
> that development time could have benefited other clients as well.

Steve did most of the work on railsifying the AMF code. All I did
was one little performance tweak I think.

> Potlatch has a very different way of interacting with the API. This way
> of interacting with the API has some benefits, and could allow for
> other clients similar to Potlatch to be developed without being tied
> explicitly to amf_controller, which is (at least at the moment)
> essentially Potlatch specific. (Things like 'masterscale' and
> 'potlatch_lon' seem to be indicate this anyway: maybe I'm wrong here.)

Yes, those are ugly glitches, and things that I would prefer to see
done on the client side. I suspect that they are mostly on the server
side for historical reasons - bear in mind that Potlatch was being
written before we moved to rails so the server side component was
originally written for the old pure ruby server environment.

>> We have in fact started moving towards that goal with some work
>> that Steve did on some of the AMF calls.
>
> This is a different goal, that of replacing SQL with rails objects. A
> valuable goal, but not the same as abstracting the data selection calls
> to a single set of code, and then using that code to serve both the main
> API and amf_controller.

You make it sound like the data selection code is horribly complicated
but really all it amounts to is a few find calls on rails classes.

That said, it would be better to common up the data selection code
as well - what we really need is a volunteer to work on this stuff.

>> The problem is that it turned out that, even after I had optimised
>> the code, it is significantly slower to go through the rails object
>> model that to make direct SQL queries.
>
> This is interesting, but (imho) less relevant: The value of the above is
> actually doubled by this statement, since if Potlatch and the API were
> using the same function, one could optimize this, and since the code is
> used by *all* clients (not just one) you would see any problems with SQL
> calls more generally, and perhaps find it easier to debug them. (I think
> this is compounded by the fact that AMF is a format which is hard to
> replicate outside of a flash client, which makes server side developers
> less likely to have the technical chops to debug them.) A common library
> for API functionality between amf_controller and the various
> api_controller methods would help resolve this to some extent.

Well the fundamental reason for the performance change is rails
and I don't think any amount of optimisation is going to help with
that - it's b