from:"D Tucny"

2009/3/6 Robert (Jamie) Munro rjmu...@arjam.net

 I hate it when I go on holiday and I can't understand the colours of the
 maps. A choice of UK Style, German Style, USA Style rendering for the
 whole world would be nice, particularly if it defaulted to whichever
 country you were in by IP address geolocation. I'm sure it will be
 easier to impliment than a single map with inconsistent syle, and I'm
 fairly confident that the resources required are not huge - particulary
 as introducing new layer servers reduces the load on the existing single
 tile server.


While I like the idea of having multiple styles available, I have to argue
that I don't believe IP address geolocation would be the 'right' way to
select a default style... IP address geolocation is something that's heavily
overused... If you take your computer with you to Paraguay, do you want the
map to default to being centered on your approximate current location? quite
probably... but, would you want the entire map/site to show in
Spanish/Guarani? Probably not, you'd probably want language to be based on
the language headers that your browser advertises it's willing to accept...
As far as default style goes, I'd suggest that after failing to find a
stored default for that particular user/browser that the user's acceptable
languages would provide a better information source for guessing a preferred
map style, i.e. if en-gb is the higher priority language, UK style, if
en-us, the US style, de, the German style etc... Obviously, it still relies
on the machine... If you are using a net bar pc in Paraguay that has a
browser configured to suggest it's willing to accept Spanish only then
whatever is used in lieu of user details or preference settings isn't
necessarily going to be ideal, but, short of making the website telepathic,
not much can be done about that...

In short, my point is, IP address geolocation can be useful for certain
things, but be careful what assumptions are made about a visitor solely
based on the location their internet access is provided from and where
possible, make it as easy for people to change their preferences to override
those assumptions...

Regarding the implementation of multiple style layers, first view
performance wouldn't necessarily be impacted, but, a larger cache would
likely be needed to store the same view with multiple layers without having
too much rerendering and for subsequent views of an already rendered area,
with 3 layers, there's a significantly increased chance that while other
people may have already viewed the same area, they may have used a different
layer and as such, the tiles still need rendering... So, the resource
requirements would increase somewhat significantly... That said, as you
said, additional tile servers would take care of those increased resource
requirements...

Apologies for the rant about IP address geolocation, as it's currently
abused by many sites and companies, it can be very very frustrating :)

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Front page design and SEO

2009/3/6 Frederik Ramm frede...@remote.org

 Hi,

 Robert (Jamie) Munro wrote:
  Yuk! No! Don't do this! Why produce half-transparent tiles when you
  could just carry on producing tiles of the neighbouring countries (or
  even the whole world) in your national style.

 As I said, that's the easy bit. We already have the whole world in
 British colours and I'm sure we will get the whole world in German
 colours (which actually I hear some cartographers refer to as the
 Michelin style so it may not be German after all) before we see
 anything fancy like I described.

 However, I still think it would be fascinating to produce ONE map (where
 you can zoom and pan across the world and don't have to stop at borders)
 and still allow national or even, sometimes, regional groups to define
 what they want on their part of the map. The practical use for the
 tourist (explain the world to me in terms I am familiar with) will be
 limited, but it will be a fantastic tool for those culturally
 interested. For example, a country in which nature reserves play an
 important role will naturally want to have them displayed at early zoom
 levels, and in other countries these might appear as a dotted line on
 z15. Same for all other kinds of things. The Iceland map will show
 filling stations at zoom level 8 ;-) and so on.

 If you don't share the vision then stick to your one size fits all
 mapping. I'm not saying we should remove that map, but I am sure that if
 we manage to create an infrastructure supporting something like that,
 then the rewards will be great. (It doesn't even have to be done by OSM
 on OSM servers, anyone can do it.)

 I am also very keen on the grassroots aspect of this. I want people to
 be able to define their part of the map without having to go via central
 command (where their request might well be met with we understand that
 you would like to have this but it has an undesirable side effect on the
 other side of the earth).


If multiple whole world style layers exist then what you suggest would be
reasonably simple to acheive, as long as the base styles were reasonably
similar and you didn't mind too much if the boundaries were a bit 'messy'...
To get a prettier single view of multiple styles with styles changing along
borders however would be somewhat trickier to acheive and I guess you'd at
least need lower zooms to be rendered with multiple styles able to coexist
in a single tile for certain areas at least, i.e. if you wanted a separate
UK and Euro style... To split the americas from the rest of the world would
be somewhat easier thanks to the large expanses of sea :)

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [OSM-newbies] avoid repeating the name tag twice

2009/3/9 marcus.wolsc...@googlemail.com

 On Sat, 07 Mar 2009 14:51:28 +0100, Pierre-André Jacquod
 pjacq...@alumni.ethz.ch wrote:
  A possibility would be to never use name=, but only name:XX= and
  have a tag name:local=XX in order to indicate which is the local one.
  For rendering, a default rule could be that if there is only one
  name:XX=xxx without name:local=... then it will use the name:XX whatever
  XX is.

 Your name:local is the same as the name everyone is already using.
 Few things actually have names in more then one language on the map.


What Pierre-André has suggested though, seems to be different to name in
that rather than having name:local contain the name, what he's actually
suggesting is that the value of name:local refers to the local language,
perhaps better named as name:local_lang, so that for Germany there would be,
for example, the following tags...

place=country
name:de=Deutschland
name:en=Germany
name:fr=Allemagne
name:ja=ドイツ
name:th=ประเทศเยอรมนี
name:zh=德国
name:local=de

Many things actually have names in more than one language on the map...
Country names, city names, and in some parts of the world, virtually every
named object have multiple language names...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Problem with osm2pgsql

2009/3/9 Peter Childs pchi...@bcs.org

 I've been trying to import the Planet file into postgres using
 osm2pgsql, Using the current SVN version, it seams to be segmenting
 when processing the first Way (Under Ubuntu Hardy). Does any one have
 any ideas, or shall I try and import a subset (The UK would fit my
 purpose) and try and get more details


Are you running the import in slim mode? What command line arguments are you
using? Do you get any warning messages?

FYI, what I used last was 'osm2pgsql -d osm -s -C 2200 -v
planet-090225.osm.bz2' to import the planet from 25th Feb to a database
named osm in slim mode with a node cache of 2200MB with verbose output...

It could be that something has changed in the latest SVN rev compared to the
rev I'm using, but, it's pretty recent...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Mapping the sea

2009/3/9 Andy Deakin andy.dea...@pcmend.net

 Hi all,

 I know this is hardly street data, but is there any undersea data in osm
 at the moment?
 e.g.
 * Ferry routes for routing between islands
 * POI's for locations of wrecks for diving
 * Navigation whilst at sea (naval charts)
 * Fishing routes, etc.

 Is there any PD(ish) elevation data for undersea to be able to mark
 contours?


There are some ferry routes in OSM... The rest I'm not sure about, but, I am
doubtful that much, if anything, exists currently...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Multilingual map

Hi folks,

I've been thinking about how it would be good to have the map available in
multiple languages... I think the easiest way to do this with what we have
is using a captionless base layer and transparent caption layers for each of
the languages... So... I put this thinking into practice and put together a
proof of concept at http://osm.newportcoastsoftware.com

There is a single base, captionless layer and 40 transparent caption layers,
all available only to zoom 8.

The name tags imported and used to make the different layers are...

name - The default name
name:ar - Arabic
name:cs - Czech
name:cy - Welsh
name:cz - Typo for Czech
name:da - Danish
name:de - German
name:el - Greek
name:en - English
name:eo - Esperanto
name:es - Spanish
name:fi - Finnish
name:fr - French
name:ga - Irish Gaelic
name:he - Hebrew
name:hi - Hindi (font problems)
name:hr - Croatian
name:hu - Hungarian
name:is - Icelandic
name:it - Italian
name:ja - Japanese
name:ja_rm - Romanised Japanese
name:kl - Kalaalisut (Greenlandic)
name:ko - Korean
name:la - Latin
name:lt - Lithuanian
name:lv - Latvian
name:nl - Dutch
name:pl - Polish
name:ro - Romanian
name:ru - Russian
name:sk - Slovak
name:sl - Slovenian
name:sr - Serbian
name:sv - Swedish
name:th - Thai
name:uk - Ukranian
name:zh - Chinese
name:zh_py - Chinese Pinyin
name:zh_pyt - Chinese Pinyin with tones

This isn't a list of all available languages in use, but, it was most of the
languages in use for names of countries and cities when I looked...

Issues:
The layer switcher is quite long with so many layers, so, the map div has
been set to 900px high to fully incorporate it... If less vertical space is
available, you'll get a scroll bar, if more is available, the map won't fill
the window...

The rendering of Hindi has been broken by missed fonts... It should be
rerendered in a while...

The tiles are bigger than the live site thanks to them not having been
created at 256 colours, this is due to transparency not currently working
with 256 colour tiles...

All tiles are prerendered... They don't get updated automatically and they
aren't rendered on request... So if you make changes to OSM, they won't show
up on this map for some time... Also nothing currently available beyond zoom
8, though I do plan on making certain areas with good examples of multiple
languages available at higher zooms...

This is just a proof of concept, it will likely disappear at some point...

If anyone has any suggestions, or sees any problems, let me know...

Thanks,

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Fwd: Multilingual map

Forward to list...

-- Forwarded message --
From: D Tucny d...@tucny.com
Date: 2009/3/9
Subject: Re: [OSM-talk] Multilingual map
To: Robert (Jamie) Munro rjmu...@arjam.net

2009/3/9 Robert (Jamie) Munro rjmu...@arjam.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 D Tucny wrote:
  Hi folks,

  I've been thinking about how it would be good to have the map available
  in multiple languages... I think the easiest way to do this with what we
  have is using a captionless base layer and transparent caption layers
  for each of the languages... So... I put this thinking into practice and
  put together a proof of concept at http://osm.newportcoastsoftware.com

  There is a single base, captionless layer and 40 transparent caption
  layers, all available only to zoom 8.

 That's great, but would it be possible for the individual language
 layers to fall back to local where a name is not given in a particular
 language?

With my first go a couple of weeks back for 8 languages I did do fallback to
at least 'name' using views as suggested on the wiki, setting this up for 40
languages however was somewhat less trivial and I felt that there would be a
benefit to being able to display languages with no fallback... I'll have a
look to see about adding additional layers with fallback...

 How much storage do the caption layers take compared to the data?

All blank tiles are removed after rendering and replaced with symlinks to
land/sea/transparent tiles...

For the captionless layers disk usage (in KB) is...
68  0
144 1
384 2
10723
32364
11420   5
37764   6
140656  7
518544  8
713288 (or 696MB)

For the caption layers...
585276  defcap
561076  arcap
560028  cscap
561132  cycap
559680  czcap
559824  dacap
562064  decap
560160  elcap
566132  encap
562140  eocap
560500  escap
561532  ficap
561000  frcap
559828  gacap
560056  hecap
559920  hicap
559916  hrcap
562472  hucap
559900  iscap
560552  itcap
560276  jacap
559752  ja_rmcap
559676  klcap
559944  kocap
560340  lacap
560240  ltcap
560188  lvcap
560284  nlcap
560620  plcap
559988  rocap
561140  rucap
559964  skcap
560072  slcap
560028  srcap
560160  svcap
559940  thcap
559924  ukcap
564112  zhcap
564088  zh_pycap
561240  zh_pytcap

So each caption layer is about 546MB with the default one being slightly
larger at 571MB...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Multilingual map

2009/3/9 Claudius Henrichs claudiu...@gmx.de

 Am 09.03.2009 13:01, D Tucny:
  Hi folks,
 
  I've been thinking about how it would be good to have the map available
  in multiple languages... I think the easiest way to do this with what we
  have is using a captionless base layer and transparent caption layers
  for each of the languages... So... I put this thinking into practice and
  put together a proof of concept at http://osm.newportcoastsoftware.com
 
  There is a single base, captionless layer and 40 transparent caption
  layers, all available only to zoom 8.

 Nice PoC, but it's surfacing some of the problems we still have with
 localization: I didn't explicitly tag the german names for countries
 where german doesn't differ from the loca name=... to avoid
 redundancy. I think the german layer should use these source for names
 in this order:
 1.) name:de
 2.) int_name
 3.) name

 I haven't checked for the mapnik syntax to do so, but maybe you could
 render it for one language as an example.



With my first go a couple of weeks back for 8 languages I did do fallback to
at least 'name' using views as suggested on the wiki, setting this up for 40
languages however was somewhat less trivial and I felt that there would be a
benefit to being able to display languages with no fallback... I'll have a
look to see about adding additional layers with fallback...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Multilingual map

2009/3/9 Celso González ce...@mitago.net

 On Mon, Mar 09, 2009 at 08:01:42PM +0800, D Tucny wrote:
  Hi folks,
 
  I've been thinking about how it would be good to have the map available
 in
  multiple languages... I think the easiest way to do this with what we
 have
  is using a captionless base layer and transparent caption layers for each
 of
  the languages... So... I put this thinking into practice and put together
 a
  proof of concept at http://osm.newportcoastsoftware.com

  This is just a proof of concept, it will likely disappear at some
 point...
 
  If anyone has any suggestions, or sees any problems, let me know...

 Could you post some of the xml used to generate the tiles?


I've put the files used to generate the tiles in
http://osm.newportcoastsoftware.com/mapnik

osm-template-local-nocap.xml is the template for the captionless layer
osm-template-local-caps.xml is the template for the captions layers
names-list is the list of names layers

osm-template-local-nocap.xml is turned into osm.xml using
customize-mapnik-map-nocap, which is customize-mapnik-map with the source
filename changed...
osm.template-local-caps.xml is turned into all the osm.xml.*cap files using
make-cap-osm-xml which is customize-mapnik-map changed to loop through the
contents of names-list to generate the osm.xml.*cap files...

Anything else, let me know...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Multilingual map

It doesn't get down to streetnames at the moment and there is only one
country and 29 cities tagged with Catalan names...

That said, I'll add it to the list of things to look at changing next time I
do an import...

d

2009/3/9 Skywave rjteh...@gmail.com

 Very nice feature, would it be possible, by any chance, to add Catalan
 names, tag name:ca. A lot of streetnames are mapped in two languages, both
 in Spain as in France.

 Skywave

 On Mon, Mar 9, 2009 at 1:01 PM, D Tucny d...@tucny.com wrote:

 Hi folks,

 I've been thinking about how it would be good to have the map available in
 multiple languages... I think the easiest way to do this with what we have
 is using a captionless base layer and transparent caption layers for each of
 the languages... So... I put this thinking into practice and put together a
 proof of concept at http://osm.newportcoastsoftware.com

 There is a single base, captionless layer and 40 transparent caption
 layers, all available only to zoom 8.

 The name tags imported and used to make the different layers are...

 name - The default name
 name:ar - Arabic
 name:cs - Czech
 name:cy - Welsh
 name:cz - Typo for Czech
 name:da - Danish
 name:de - German
 name:el - Greek
 name:en - English
 name:eo - Esperanto
 name:es - Spanish
 name:fi - Finnish
 name:fr - French
 name:ga - Irish Gaelic
 name:he - Hebrew
 name:hi - Hindi (font problems)
 name:hr - Croatian
 name:hu - Hungarian
 name:is - Icelandic
 name:it - Italian
 name:ja - Japanese
 name:ja_rm - Romanised Japanese
 name:kl - Kalaalisut (Greenlandic)
 name:ko - Korean
 name:la - Latin
 name:lt - Lithuanian
 name:lv - Latvian
 name:nl - Dutch
 name:pl - Polish
 name:ro - Romanian
 name:ru - Russian
 name:sk - Slovak
 name:sl - Slovenian
 name:sr - Serbian
 name:sv - Swedish
 name:th - Thai
 name:uk - Ukranian
 name:zh - Chinese
 name:zh_py - Chinese Pinyin
 name:zh_pyt - Chinese Pinyin with tones

 This isn't a list of all available languages in use, but, it was most of
 the languages in use for names of countries and cities when I looked...

 Issues:
 The layer switcher is quite long with so many layers, so, the map div has
 been set to 900px high to fully incorporate it... If less vertical space is
 available, you'll get a scroll bar, if more is available, the map won't fill
 the window...

 The rendering of Hindi has been broken by missed fonts... It should be
 rerendered in a while...

 The tiles are bigger than the live site thanks to them not having been
 created at 256 colours, this is due to transparency not currently working
 with 256 colour tiles...

 All tiles are prerendered... They don't get updated automatically and they
 aren't rendered on request... So if you make changes to OSM, they won't show
 up on this map for some time... Also nothing currently available beyond zoom
 8, though I do plan on making certain areas with good examples of multiple
 languages available at higher zooms...

 This is just a proof of concept, it will likely disappear at some point...

 If anyone has any suggestions, or sees any problems, let me know...

 Thanks,

 d

 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk



 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Front page design and SEO

2009-03-03 Per discussione D Tucny

2009/3/3 Tom Hughes t...@compton.nu

 D Tucny wrote:


 I must say, I like that one too... but... So many sites and applications
 these days seem to be going with all the options at the top/bottom and a
 full width content section, while at the same time most 4:3 screens are
 being replaced with 16:10 screens...


 Screen size is of course irrelevant to browser window size, unless you're
 one of those weird web designers that seems to think everybody runs their
 browser full screen all the time...


I guess that makes me a weird web user for always having browsers full
screen... Or at least, someone without enough screen space to comfortably do
otherwise :(...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Front page design and SEO

2009-03-02 Per discussione D Tucny

2009/3/3 Ian Dees ian.d...@gmail.com

 On Mon, Mar 2, 2009 at 9:51 PM, SteveC st...@asklater.com wrote:


 I asked the CM designers for some quick hacks on what different front
 pages could look like which you can see on the wiki page below. There
 are some very quick ideas there but it's not a full picture by a long
 way.


  To get some conversation going:

 I really like the Fp4.jpg[1] example on the URL you gave, Steve. It's
 important to make the map (and thus its data) the largest GUI element on the
 page. The buttons along the top draw my eye up there to see what's
 available. I also like the Shop link idea.

 After looking at all of the examples, Fp4.jpg seems to be the one that is
 the simplest and most eye-catching.

 [1] http://wiki.openstreetmap.org/wiki/Image:Fp4.jpg


I must say, I like that one too... but... So many sites and applications
these days seem to be going with all the options at the top/bottom and a
full width content section, while at the same time most 4:3 screens are
being replaced with 16:10 screens... Though at least most sites allow the
content to be scrolled moving their menu bars out of view, this however,
proboably isn't something that would be preferable with the OSM page... The
end result being that with a layout like that on a widescreen display,
you'll have browser title bar, menu bar, link bar, tab bar, random other
tool bars, osm tab bar, small, but, wide, sliver of map, osm key bar,
browser status bar and finally task bar...
Obviously if you have a big screen with a decent vertical resolution, the
sliver of map is somewhat larger and more useful, but, on smaller screens at
least, and I'm thinking of screens with a resolution like 1280x800 here that
are pretty common in laptops these days, that sliver isn't going to be that
big... As such... I think the fp6/7 images would be probably better
generally, and especially for smaller widescreen displays...

That said, I guess there's no reason, beyond maintainability, why both
layouts couldn't be made available, even if only selectable by logged in
users... though a default that's good for everyone would still be needed
:)...

I think all the samples shown are an improvement on the existing layout in
term of usability and from an aesthetics point of view, making things
clearer and prettier at the same time :)

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Mapnik coastline shapefile update - Philippine coast still somewhat square when exported

2009-03-02 Per discussione D Tucny

2009/3/3 Jon Burgess jburgess...@googlemail.com

 On Mon, 2009-03-02 at 10:51 +, Kevin Peat wrote:
  I made some changes a couple of weeks ago to the banks of the River
  Dart
  through Totnes
 
 
 http://www.openstreetmap.org/?lat=50.42863lon=-3.67974zoom=15layers=B000FFF
 
  Obviously those changes have been picked up as the county boundary is
  rendering along the updated river bank but the actual river isn't.
 
  Is this just a time lag thing or have I done something wrong?

 There is a lag. The coastlines are generated from a set of shapefiles
 which is periodically updated from the OSM data. I've just fetched the
 latest updates.

 You probably won't see much difference in the map tiles until the
 weekend, but images from the export tab will show them right away (see
 attached).


There's a large chunk of bad coastline around The Philippines that's been
there since some shapefile update in the recent past...

It can be seen here...
http://www.openstreetmap.org/?lat=15.481lon=120.274zoom=9layers=B000FTFT

The coastline is all OK now (there were a couple of problems at one point)
and the view at the coastline checker (
http://tile.openstreetmap.nl/coastlines.html?lat=15.481lon=120.274zoom=9)
and a local mapnik render I've done using the coastline checker output both
show the coastline correctly...

A trac ticket was raised about this problem a couple of days ago now, but,
I'd have expected an update of the shapefiles to have corrected this... It
looks like it's only corrected the problem above zoom level 10 though
suggesting that only the processed_p shapefiles have been updated...

So... some questions...
Is there a problem with the world boundaries shapefiles being used? Were
they generated from the processed_p shapefiles at some point? Are the world
boundaries files used on tile different to the ones packaged here
http://tile.openstreetmap.org/world_boundaries-spherical.tgz? What would be
involved in regenerating them? Once regenerated, could new ones be made
available somewhere?

Thanks,

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [talk-ph] Luzon Coastline

2009-02-23 Per discussione D Tucny

It's all looking fine at the moment...

http://osm.newportcoastsoftware.com/?zoom=11lat=14.80342lon=120.25358layers=0BTFF
http://osm.newportcoastsoftware.com/?zoom=8lat=14.80342lon=120.25358layers=0BTFF

This view should be the coastline of the Philippines as produced by the
coastline checking tools, plus captions of points (which is additional local
layer) up to zoom 12...

The coastline is showing as all white, which shows it's thought to be
complete... there were 9 errors that showed up in the processing, but, I've
not worked out how to make them display on the render yet... I did however
find one on the main coastcheck at, which could be a 9 node way I guess...

http://tile.openstreetmap.nl/coastlines.html?zoom=14lat=12.8092lon=123.26351layers=B00T

The output from the script was as follows if anyone is interested...

osm2coast SVN version 0.12-20090223 $Rev: 4895 $

Reading in file: philippines.osm.bz2
Processing: Node(204k) Way(1k) Relation(0k)
Reading in file: philippines.osm.bz2
Processing: Node(204k) Way(1k) Relation(0k)
Node stats: total(204783), max(349935162)
Way stats: total(1642), max(31405371)
Relation stats: total(0), max(0)
Pass 1: Collecting ways
887 collected, 755 closed, 0 zero-length
Pass 2: Starting with 887 ways (epsilon=0.001)
Pass 2a: Adding to R-Tree
Pass 2b: Joining ways
Remain: 3 / 887 (complete 41)
Pass 2c: Consolidate remaining
Consolidated: 3
Pass 3: Starting with 3 ways (epsilon=0.01)
Pass 3a: Adding to R-Tree
Pass 3b: Joining ways
Remain: 3 / 887 (complete 41)
Pass 3c: Consolidate remaining
Consolidated: 3
Pass 4: Starting with 3 ways (epsilon=0.1)
Pass 4a: Adding to R-Tree
Pass 4b: Joining ways
Remain: 2 / 887 (complete 41)
Pass 4c: Consolidate remaining
Consolidated: 2
Dumping remaining
Total ways output: 887
ERROR: ld.so: object '/root/libtcmalloc.so' from LD_PRELOAD cannot be
preloaded: ignored.
ERROR: ld.so: object '/root/libtcmalloc.so' from LD_PRELOAD cannot be
preloaded: ignored.
coast2shp SVN version 0.12-20090223 $Rev: 4895 $

Reading in file: data/coastline.osm.gz
Processing: Node(204k) Way(1k) Relation(0k)
Reading in file: data/coast-merged.txt
Max vertex count: 40137
Polygons: 796, Arcs: 2

Node stats: total(204783), max(349935162)
Way stats: total(1642), max(31405371)
Relation stats: total(0), max(0)
Resizing subarea array to 1024
Arc: Found 1 large objects out of 2, removed 0+0 nodes, approx memory 0.0MB
Polygon: Found 16 large objects out of 796, removed 0+0 nodes, approx memory
0.0MB
Processing (399,399)  (19937170.09,19937170.09)-(20037508.00,20037657.62)
max tree depth:8
split ratio:0.55
processing data/coastline_c
9994
length=1615026
version=1000
type=5
extent:Envelope(13246555.08273602,511168.6087117034,14093233.21979928,622.647261268)
 number shapes=796
 number nodes=755
processing data/coastline_i
9994
length=51586
version=1000
type=3
extent:Envelope(13149609.56089878,536857.1137060019,13326797.60526562,1280527.678805463)
 number shapes=2
 number nodes=1
*processing data/coastline_p*
9994
length=176
version=1000
type=1
extent:Envelope(13155077.63132714,536857.1137060019,13244607.33367305,1158474.414221474)
* number shapes=9
 number nodes=9*
*processing data/processed_p*
9994
length=1665602
version=1000
type=5
extent:Envelope(13224604.96875,511168.6087117034,14093233.21979928,622.647261268)
* number shapes=980
 number nodes=827*
*processing data/processed_i*
9994
length=51586
version=1000
type=3
extent:Envelope(13149609.56089878,536857.1137060019,13326797.60526562,1280527.678805463)
* number shapes=2
 number nodes=1*
done!

Bold are the key bits, coastline_p contains errors, processed_p contrains
the main coast polygons and processed_i contains the incomplete coastline,
which, for this is where the bounding box of the data extract cut of some
coast...

I hope this helps,

d

2009/2/23 Jim Morgan j...@datalude.com

 D,

 Excellent. Someone who clearly knows what they're talking about.

 I'm extremely happy to hand this one off to you - you might have guessed I
 was stabbing in the dark there, but it seemed like too big an issue to leave
 alone. I'll keep my meddling browser out of there from now on ...

 I wasn't sure of the significance of the layer=-1 either, but as it was
 already there I left it in. Feel free to change this if it doesn't look
 right to you.

 Thanks for the tip about keeping coastlines down to ~ 250 node sections.
 Didn't see any mention of this in the literature, so its worth publicising
 this ...

 Jim

 D Tucny wrote, On Monday, February 23, 2009 02:51 PM:
  That section of coastline is now 2193 nodes, this will be too big for
  the 0.6 version of the API, coastline imported by the coastline import
  tool would typically make ways of up to 250 nodes if I recall correctly,
  over 2000 nodes will be a definite problem... It's an odd bit of
  coastline tagging though, layer=-1 stands out as the strangest bit...
 
  Along that section of coastline there are some odd bits that could
  potentially confuse rendering

[OSM-talk] OSM on The Reg

2009-02-11 Per discussione D Tucny

http://www.theregister.co.uk/2009/02/10/brum_map/

Couple of nice links there, both to the map and the home page...

Comments in the comments section are largely at the same level of
positiveness and understanding as is largely normal on the reg these days
(read mostly negative)...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Mapnik updating more frequently?

2009-02-09 Per discussione D Tucny

2009/2/10 David Lynch djly...@gmail.com

 Is the mapnik render now updating more frequently than once a week?
 I'm seeing buildings that I added a couple hours ago appearing on
 there before even ti...@home/osmarender gets to them.


I don't recall seeing anything about it, but, I can see things showing on
the mapnik layer that I added yesterday...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Long Ways and API 0.6

2009-02-08 Per discussione D Tucny

2009/2/9 Frederik Ramm frede...@remote.org

 Hi,

 MP wrote:
  The advanced usage of the multipolygon relation allows you to have as
 many
  outer members as you want (see wiki page), so you can just split up
 your
  outer way and that's it. It probably isn't perfect in the renderers yet
 but
  I'm confident it will soon be.
 
  Automatic multipolygon splitting, where inner parts will
  _automatically_ move to correct half would make this relatively easy
  problem to solve.

 You misread me. You simply take the existing outer way, split it into 5
 little bits, make sure they are all member of the relation, and that's
 it. No need to move inner polygons to the correct half because there
 is no half.


IIRC, just splitting the ways in JOSM would result in the smaller ways all
being members of the relation as the same object type as the original larger
way by default... So, split the outer into two in JOSM and you automagically
have two outer ways in the same relation...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Hit my server

2009-02-07 Per discussione D Tucny

2009/2/7 Chris Hill chillly...@yahoo.co.uk

 Jonas Svensson wrote:
  I have set up a temporary openlayers/mapnik-server at
  http://www.mozoft.com:9980/tms.html. It can't take much load
  initially when rendering tiles, but I am curious about what happens
  later when the cache is covering most. So please feel free to hit
  it it! It will only be availabe for a few hours.
 
  /Jonas
 
 
  ___
  talk mailing list
  talk@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk
 
 
 I looked at my home patch (lat=53.74 lon=-0.49). There was a long and
 fruitless delay zooming in to a new area for the first time, but
 returning after a while it performed well.  The highest zoom level was
 about z15.  May I ask what you learned and what you plan to use it for?


Works OK for me too, with a delay...

One thing I did notice, it does seem to do an interesting name language
preference with fallback, not sure what the order is though...


d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Tilesathome] setting up a server for a country

2009-02-04 Per discussione D Tucny

2009/2/4 Dirk-Lüder Kreie osm-l...@deelkar.net

 ti...@home, while very up-to-date is a very inefficient rendering
 process and work has been put into enabling mapnik to be as up-to date
 as t...@h can be. (see up-to-date bookmarklet by crschmidt)


Or... http://matt.sandbox.cloudmade.com/

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Tilesathome] setting up a server for a country

2009-02-04 Per discussione D Tucny

2009/2/5 Kenneth Gonsalves law...@au-kbc.org

 On Wednesday 04 Feb 2009 10:15:13 pm 80n wrote:
  Except, AIUI, the motivation is entirely because Mapnik can't handle the
  wide variety of Indian scripts: Hindi, Bengali, Tamil etc.

 actually mapnik relies on DejaVu - we plan to add the Indian scripts to
 DejaVu, which will solve this problem.


This isn't the case anymore... Mapnik supports fallback these days... There
may be an issue with it's shaper though...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Karlsruhe schema and buildings with several house numbers

2009-02-03 Per discussione D Tucny

2009/2/4 Frédéric Bonifas fredericboni...@gmail.com

 Hi,

 As we are now allowed to use the French cadastre to add data to OSM, I
 am mapping buildings in Grenoble (

 http://informationfreeway.org/?lat=45.18877199061041lon=5.723019237090732zoom=17layers=BF000F
 )
 But I have a problem : sometimes, the same building has several house
 numbers :
 * it can be several numbers one the same street
 * a building can also have house numbers in different streets.

 Here is an example of a building with the 2 problems :
 http://fredericbonifas.free.fr/building_housenumbers.png

 Is there a proper way to tag the house numbers in this case ?


I've put numbered nodes along the edges when I've had this, it confuses
JOSMs orthogonalise function though...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Error in Google-Maps

2009-01-28 Per discussione D Tucny

2009/1/28 andrzej zaborowski balr...@gmail.com

 2009/1/28 Jürgen Reimann juergen.reim...@gmx.de:
  Hello, please don't shoot me if I'm absolutely wrong at this place. I
 want
  to ask what is to be done if a strange error in Google-Maps appears.

 This might be a wrong list to ask about Google Maps.

  This map (like OSM) should also be free of strange mistakes. Does anybody
  know, who (in person) is responsible for the information
  provided by Google-Maps. (I think even OSM is not absolutely correct in
 this
  area - I have to check it this weekend).
  Please have a look at this area and you know what I mean:
  http://sautter.com/map/?zoom=17lat=51.12995lon=6.46463layers=B000TFFF

 Check out
 http://sautter.com/map/?zoom=14lat=-5.06418lon=-39.0461layers=B000TFFF
 , this whole region on Google Maps is somebody's rich imagination and
 lots of creativity.  Roads are  20km off.


That looks like vmap0 level of quality...

The vmap0 dataset seems to have been used by a number of mapping providers
as at least the base for parts of the world where they have no coverage, the
resolution is incredibly low and the quality is horrible... What it does do,
is make it look like there is map coverage in an area that would otherwise
just be blank, of course, it's of virtually no use to anyone...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Error in Google-Maps

2009-01-28 Per discussione D Tucny

2009/1/29 D Tucny d...@tucny.com

 2009/1/28 andrzej zaborowski balr...@gmail.com

 2009/1/28 Jürgen Reimann juergen.reim...@gmx.de:
  Hello, please don't shoot me if I'm absolutely wrong at this place. I
 want
  to ask what is to be done if a strange error in Google-Maps appears.

 This might be a wrong list to ask about Google Maps.

  This map (like OSM) should also be free of strange mistakes. Does
 anybody
  know, who (in person) is responsible for the information
  provided by Google-Maps. (I think even OSM is not absolutely correct in
 this
  area - I have to check it this weekend).
  Please have a look at this area and you know what I mean:
 
 http://sautter.com/map/?zoom=17lat=51.12995lon=6.46463layers=B000TFFF

 Check out
 http://sautter.com/map/?zoom=14lat=-5.06418lon=-39.0461layers=B000TFFF
 , this whole region on Google Maps is somebody's rich imagination and
 lots of creativity.  Roads are  20km off.


 That looks like vmap0 level of quality...

 The vmap0 dataset seems to have been used by a number of mapping providers
 as at least the base for parts of the world where they have no coverage, the
 resolution is incredibly low and the quality is horrible... What it does do,
 is make it look like there is map coverage in an area that would otherwise
 just be blank, of course, it's of virtually no use to anyone...

 d


Of course, OSM isn't perfect...

http://sautter.com/map/?zoom=11lat=29.60689lon=112.12921layers=B000FTFF

I'm pretty sure there's no grid of motorways there... :/

There might be a grid of roads though, so seems like a new mapper
potentially needs some prodding towards the documentation... I'll go do
that...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] 26 languages

2009-01-24 Per discussione D Tucny

2009/1/25 Colin McGregor colin.mc...@gmail.com

 On 1/24/09, Frederik Ramm frede...@remote.org wrote:
  Hi,
 
  Lars Aronsson wrote:
  After Portuguese and Afrikaans have been added, there are now 28
  languages. But of the largest Wikipedia languages, we're still
  missing Japanese (5th biggest) and Chinese (12th).
 
  Why bother educating the Chinese about OSM when they will be jailed
  trying to contribute?


Might be best not putting any Indian languages up though, mapping there will
get you jailed, and may be best removing the English too, I wouldn't like to
think what could happen or where you'd be sent if you were spotted doing
something suspicious like walking around with a GPSr, a voice recorder, a
camera and a backpack in at least the US, especially if you looked
'foreign'... There isn't even a great firewall in those locations to protect
people from seeing things they shouldn't ;)



 The answer is simple and obvious, not all Chinese speaking people live
 in China. I live in Toronto, Ontario, Canada, and some 11% of the
 population (over 280,000 people) is of Chinese decent, and relevant
 for the likes of a Wikipedia entry, manages to support three daily
 Chinese language newspapers...

 So, for the benefit of oversees Chinese a Wikipedia entry would be a
 good thing (the more mappers the better in my books).


There are 100s of thousands of Chinese students studying abroad... figures
I've seen suggested 12 in the EU alone in 2007... The US, Canada and
Australia are also common destinations for Chinese students looking to study
abroad, with the US apparently having over 8 Chinese students in
2007-2008... Of course, there are stats such as this 'The number of people
studying abroad totalled 1.2117 million from 1978 to 2007, among which
319,700 have already returned.' which suggests that between 1978 and 2007
1.2 million people went to study abroad and 90 haven't returned yet...

So, there are plenty of Chinese people outside China who's first written
language is Chinese...

But, within China, while there has been the obvious press that people have
been fined and expelled for illegal mapping, the stories are mostly
specifically about foreign nationals who've entered China only to perform
surveying, including surveying airports/airbases...

China has massive amounts of effort going into mapping, with billions ($ I
think) being put into projects in recent years to make accurate enough maps
that they can be used with GPS devices... Not all the efforts are state
based though... There is also a lot of mapping for profit going on... GPS
devices are very popular with satnav in car devices very common... A pretty
massive number of brands exist, all competing with very similar products,
map data comes from all over the place and up to date POIs are typically
seen as one of the most important aspects of the data, something especially
relevant considering the rate of change and development... There and lots of
companies involved, all trying to build their own dataset for profit... Some
licensed, but most probably not...

And this is just part of the situation with maps in China...

A report last year some time said that there were over 1 websites in
China that contained unauthorised maps, huge demand for mapping data and
limited general availability of quality authorised data were I believe cited
as a potential cause...

10 years ago there was not much in the way of publicly available maps, now
there are maps everywhere... even on every street corner, at least in
touristy places... Quality is still an obvious issue... Availability of data
is still an issue, though state data is available more and more and is
becoming more and more open, partly to encourage use of the official state
data in preference to data from other sources...

China's legal system is still growing, maturing and developing, like most
things in China... Things are improving all the time... The place is not at
all like is portrayed in most Hollywood movies, in many ways it's more free,
open and in many cases commercial than you probably imagine...

At the end of the day, for people in China, if the authorities don't want
them to see a site on the internet, it'll get blocked... Wikipedia itself
has been blocked for large amounts of time with the non-chinese versions
coming and going and more recently the chinese version becoming available
and staying available... There is still blocking of certain wikipedia pages
where the content is deemed unsuitable either by the filtering software or
the decision makers that control the filtering rules...

So... If the information about OSM is put on wikipedia in Chinese, there are
millions of people outside of mainland China that could find the translation
useful, there are many more within China that could be interested to read
about it even if they don't then go on to contribute and if it is considered
to be unwanted by whichever people/departments make those choices, it'll get
blocked

Re: [OSM-talk] Import populated places from vmap0

2009-01-21 Per discussione D Tucny

2009/1/22 Upliner Mikhalych upli...@gmail.com

 2009/1/21 20:48 Hakan Tandogan wrote:
  Maybe you could do a comparision to geonames.org, and add only places
 that
  have a similiar spelling in their russian name?
 Geonames is rejected datasource for OSM according to wiki. So I'm not
 sure that it is good idea to use their data for import.


GNS however is a valid source...
http://earth-info.nga.mil/gns/html/index.html

The country file for russia is 28MB zipped (83MB unzipped) with 547909
records...

It's supposed to include a PC field for importance level, but, it doesn't
seem to be populated in the Russia data, also, supposed to include
population, but, that's also missing...

I modified my GNS extract script to interpret the data and merge the russian
cyrillic and local latin names into a single record... about 99% of records
have a latin format name, about 50% have cyrillic (judged by eye)...

I'm just looking at mapping the correct feature types and looking at the
possibility of matching administrative records to populated place records in
an attempt to calculate place size...

e.g.
Place with no indication of type of place
4   -30039916879674 56.851944   41.36   565107
412144  37VFD4405303392 NO37-12 P   PPL RS
21  NS rus  ШУЯ
Шуя Шуя 2007-02-12
4   -3003991-420954956.851944   41.36
565107  412144  37VFD4405303392 NO37-12 P   PPL RS
21 NSHUYA   Shuya   Shuya   2007-02-12

and
Admin level 2 object mentioning it's a city...
4   210856  263607  56.85   41.37   565100  412200
37VFD4433103185 NO37-12 A   ADM2RS
21  N  Gorod
GORODSHUYA  Gorod Shuya Gorod Shuya 2007-02-12
4   210856  6678714 56.85   41.37   565100  412200
37VFD4433103185 NO37-12 A   ADM2RS
21  NS  rusГород
ГОРОДШУЯГород Шуя   Город Шуя   2007-02-12
4   210856  6877547 56.85   41.37   565100  412200
37VFD4433103185 NO37-12 A   ADM2RS
21  NS  rusГород
ГОРОДШУЯГород Шуя   Город Шуя   2007-02-12

Perhaps it might be best to just use the ADM objects rather than the PPL
objects, but, you can't get smaller places then and the ADM objects tend to
be placed further from the center of a place than the PPL objects...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] name tags on place=country and how they're rendered on lowzoom

2009-01-20 Per discussione D Tucny

2009/1/19 Robert (Jamie) Munro rjmu...@arjam.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 ビカス ヤダワ (vikas yadav) wrote:
  where is a local language being set for a country or a region?

 By the country or regions government, usually.

 I think there is a misunderstanding going on here. If I speak English, I
 want and English map of the world. If I speak French, I want a French
 map of the world. In neither case do I want a map that has England in
 English and France in French. IMHO, the correct procedure for drawing a
 map is to:

 1. Decide what language your map is in.
 2. Look for name:[language]= tags and draw them
 3. Look for name= tags where the one for your language doesn't exist.

 The problem is that the default maps generated by the project (mapnik
 and osmarender) both get this wrong. They omit step one, and try to
 pretend that the map can be not in any particular language.


It's obviously a preference thing then...  I'd prefer a map that had the
real names of features rather than whatever, potentially dodgy, translation
any other language had... I admit that it might be useful, especially with
non-latin character based languages to view alternative, potentially latin
variant names as an option, but, that shouldn't, I believe, be the
default...

Yes, making the maps available in different languages would be good, and the
idea of separating captions out into their own layers might be the best
approach to that, but, if we have any sort of default I believe it should
reflect the real feature names in their native language... This is what I
would expect...

I think your correct procedure for drawing a map could only be applicable if
you had a limited audience... OSM has an unlimited audience... The default
view of the map can't/shouldn't be targetted at a specific language in my
opinion...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [talk-ph] Hi Guys and Gals, Open Street Map.

2009-01-18 Per discussione D Tucny

2009/1/19 Michael Cole colemic...@gmail.com

  Hi I am going to be setting up a server using the Philippine map mainly,
 Later we will be using the whole planet files,

 But i have notice some errors in the files i have downloaded so far,Towns
 are categorized in the wrong province, Or if they are not then the
 boundaries are wrong.

 I would like to get all the data correct I currently use our own database
 of locations and Points of interest overlayed on the Google map but the
 google map is so far out in the streets.

 I saw you have meet ups at times, When is your next one?

 Does anyone here sell a GPS logging device. So I can send it out with my
 partners and others to collect data which so far has not been mapped.

 I have a Bluetooth device myself and i am using my own program written in
 Python on the N70 Nokia phone.. For that device i would like to also get an
 external Antenna?

 Or is there a good shop here in Metro Manila where i can get GPS supplies
 last time i tried i just got the run around or they were trying to charge me
 triple the actual price.

 Anyway guys and gals have a good week and i hope i can help you all with
 the great work you have done so far.

 P.S. Makati Police station headquarters has moved, I went to where the old
 one was a few weeks ago and noticed it had moved.. I will see if i can move
 it.. Have to work out how to use all these programs..


Welcome!

If you have some examples of bad data, please share it (or fix it yourself
:)) I'm not sure where the place and boundary information has come from,
but, it could have been an import from somewhere, in which case it would be
good to know where the errors exist...

Everyone is working on trying to get the data correct, more hands will
surely help :)

There is a meetup currently being organised, current favourite date appears
to be 7th Feb... I'm sure Maning will jump in shortly to give more
details...

I'm not sure if there's anywhere good to get GPS kit of accessories in Metro
Manila, the last time I looked, as you said, prices were insane... This
reflected the situation with most electrical items though, in many cases it
was cheaper to buy electrical items outside of the Philippines even after
import duties, tax and shipping were added on top even if local sales tax
had already been paid in the source country and in many cases this was the
only option as local suppliers couldn't get hold of specific required kit...
In the cases where hardware was bought locally, it was only after massive
price cuts has been given following our suggestion that we would import
stuff ourselves... The massive overpricing of hightech/electrical goods is
definitely not good for the Philippines...

Depending on how far the police HQ as moved, it might be easier to recreate
it at the new location and remove the old one... I'd guess it's not moved
too far though, but, if using Potlatch, you may need to move it a bit at a
time... In JOSM you could Cut it from the old location and Paste it into the
new one...

Have a look on the wiki (wiki.openstreetmap.org) for some useful information
on the programs, and, don't be afraid to ask people if you need some help :)

d
___
talk-ph mailing list
talk-ph@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ph

Re: [OSM-talk] Tagging for general household shop

2009-01-18 Per discussione D Tucny

Agreed, convenience would cover 7-Eleven in the US, HK, PH (and other places
it's spread to), Spar in the UK, C-Store/Kedi/Quik etc in CN etc...
While the shop that seems to being described would be more similar to
Woolworths in the UK (at least as it was in the decade preceeding it's death
iirc), selling household wares...

d

2009/1/19 Cartinus carti...@xs4all.nl

 AFAIK a convenience store sells mostly consumables, while the kind of shop
 Martijn is talking about mostly sells hardware for mum (to phrase it
 politically incorrect).

 On Sunday 18 January 2009 17:14:47 Mike Harris wrote:
  Surely this is shop=convenience - for what Americans (and increasingly
  Brits too!) call a convenience store. From what I recall of trips to NL
  this is what Blokker etc. is - but perhaps I have misunderstood?
 
 
  Mike Harris
 
  -Original Message-
  From: Martijn van Exel [mailto:mve...@gmail.com]
  Sent: 17 January 2009 18:01
  To: OSM Talk
  Cc: OpenStreetMap NL discussion list
  Subject: [OSM-talk] Tagging for general household shop
 
  Hi all,
 
  In NL, we have a breed of shops, represented by a small number of chains
  (Blokker, Marskramer, may be one or two more) that 'specialise'
  in all kinds of general household necessities, ranging from bin liners to
  ironing boards and from cutlery to adhesive tape and even small household
  appliances. It is definitely not a department store - it's much smaller
 and
  does not have distinguishable departments. It is also not a specialty
 store
  - they focus on affordable, main stream household products.
 
  Going by this description, is there a tag that you think covers this?
  Otherwise I will introduce shop=household.
 
  Take care,
  --
  martijn van exel -+- mve...@gmail.com -+- http://www.schaaltreinen.nl/

 --
 m.v.g.,
 Cartinus

 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] extracts of OSM

2009-01-18 Per discussione D Tucny

2009/1/19 David Bannon d.ban...@vpac.org

 Hi Folks, some advice please ?

 I am interested in getting some OSM data covering the north of the North
 Island of NZ, some where I am visiting shortly. However, there is not
 extract available and its too big to pull down from the OSM website.

 Seems my only choice is to pull down the while planet, and at 5 G thats
 not really a choice when I am on the road

 Any suggestions ?



There is an extract of NZ at
http://downloads.cloudmade.com/oceania/new_zealand which is 6.6MB compressed

Alternatively, you can use the OSMXAPI to download chunks of data defined by
a bounding box (http://wiki.openstreetmap.org/wiki/Xapi) which allows for
larger boxes than the standard API...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Language rendering query

2009-01-16 Per discussione D Tucny

2009/1/16 Ted Mielczarek ted.mielcza...@gmail.com


 On Thu, Jan 15, 2009 at 3:31 AM, D Tucny d...@tucny.com wrote:

 Not now it doesn't... jth did the last render and is obviously missing
 fonts needed... however, it seems some people do have OK fonts...


 Does t...@h require the correct fonts to be installed on the user's machine?
 That seems pretty suboptimal. Couldn't it ship a free font with the software
 and use that?


The t...@h installation instructions tell you to install the DejaVu font, a
free font, however, it's coverage, as can be seen here
http://dejavu.svn.sourceforge.net/viewvc/*checkout*/dejavu/trunk/dejavu-fonts/langcover.txtis
missing some pretty large chunks that would likely take significantly
more effort than has so far gone into the font to fill... as such, to render
any of the missing languages (listed below) alternative fonts are needed...

Amharic
Bihari (Devanagari script)
Bhojpuri (Devanagari script)
Bengali
Tibetan
Cherokee
Dzongkha
Ethiopic (Geez)
Gujarati
Hindi (Devanagari script)
Japanese
Khmer
Kannada
Korean
Kokani (Devanagari script)
Kashmiri (Devanagari script)
Malayalam
Mongolian
Marathi (Devanagari script)
Burmese (Myanmar)
Nepali (Devanagari script)
Oriya
Punjabi (Gurumukhi script)
Sanskrit (Devanagari script)
Sinhala (Sinhalese)
Syriac
Tamil
Telugu
Thai
Eritrean Tigrinya
Ethiopian Tigrinya
Tigre
Tagalog
Chinese (simplified)
Chinese Hong Kong Supplementary Character Set
Chinese in Macau
Chinese in Singapore
Chinese (traditional)

There is at least some overlap with some of those languages, and some of
those will not be in common use, at least for naming, but, that is just a
list from the linked completion report above...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Language rendering query

2009-01-15 Per discussione D Tucny

2009/1/15 Kenneth Gonsalves law...@au-kbc.org

 On Thursday 15 Jan 2009 1:07:57 pm Vikas Yadav wrote:
  yippeee! default name key seems working!
  http://c.tah.openstreetmap.org/Tiles/tile/12/2924/1709.png

 doesnt look like devanagiri or gurmukhi to me


Not now it doesn't... jth did the last render and is obviously missing fonts
needed... however, it seems some people do have OK fonts...

New Delhi looking somewhat off...
http://server.tah.openstreetmap.org/Browse/details/tile/12/2926/1708/
but the tail half of the name looking OK...
http://server.tah.openstreetmap.org/Browse/details/tile/12/2927/1708/

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] name tags on place=country and how they're rendered on lowzoom

2009-01-14 Per discussione D Tucny

2009/1/15 Sascha Silbe sascha-ml-gis-osm-t...@silbe.org

 On Wed, Jan 14, 2009 at 08:14:21PM +, ?var Arnfj?r? Bjarmason wrote:

  * Most have the common English name in the name= field, e.g. Germany and
 Andorra

 At least for Germany, this has already been fixed on 2008-12-04.
 name=* (without a language code) should be the name in the local language.

 From the wiki page defining the meaning of name [1]:

 name=Irgendwas(the default name, used locally)
 name:en=Something (the name in English)



 [1] http://wiki.openstreetmap.org/wiki/Key:name


+1

As I see it, the default render shouldn't be English, it should be using the
local name of each location/object...

If/when we get caption layers for different languages, then, the English
caption layer would contain the English names of countries, and this would
be OK as the user could choose to view data in English, equally, someone
could choose a Chinese layer to view the Chinese names of countries or a
Japanese layer to view the Japanese names of countries...

Also, if someone so desired, they could make a caption layer that
incorporated the local name with English or a combination of languages in
smaller text below the local name, or the local name followed by the English
name in parentheses...

I feel that the approach of putting multiple languages into the name tag
when there are not multiple local languages is at least not good as I see it
as being tagging for the renderer(s) in their current state, rather than
providing all the information in such a way as the renderer can use it as
they see fit...

The one exception I see, which I'm not sure on how best to handle, is
countries that have multiple official languages and as such, multiple
official names... I believe this to be the case at least with Belgium and
Switzerland for example where there are multiple valid local names depending
on the language used in a certain part of the country (plus latin for
Switzerland)...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Language rendering query

2009-01-14 Per discussione D Tucny

2009/1/15 Vikas Yadav vikas.ya...@threebrix.com

Hi,

I had two queries:
1) New Delhi text is not visible on low zooms (like 8) and is only seem
even after other smaller cities are shown. Please suggest how to fix it. (I
had put the same question on other thread a while back with no response. :(

http://www.informationfreeway.org/?lat=19.268965272384115lon=77.80076850988954zoom=4layers=0F0B0F
It's showing up at zoom 4 there...

2) Need to know how to show hindi translations on north indian cities when
they are rendered. I had put up a half dozen city name:hi just yesterday.
what else should be done so that mapnik/tah start rendering the translations
in the language? (Just like shown in Sri Lanka/China/etc)

While it's useful to have the hindi name in name:hi, it may also be
worthwhile putting it in name if the local language is officially hindi...
If name currently contains an English name, that can be moved to name:en.

I'm not sure however that there are suitable fonts on the mapnik tile server
or ti...@home clients to correctly render hindi (the DejaVu font does not
have full UTF8 coverage), so making this change may result in names not
being visible on the map until this problem is corrected... (Right now
non-latin rendering on ti...@home is pretty haphazard as some clients have
suitable fonts for some languages and others don't, Mapnik didn't used to
support glyph fallback, so any characters not present in DejaVu were
rendered as squares, it now supports glyph fallback however and the server
seems to have a reasonable range of fonts available which means that it's
consistent rendering of non-latin scripts has suddenly overtaken
ti...@homein this regard)... If you find that hindi does not render
correctly on the
Mapnik layer, it would likely be useful to raise a trac ticket with some
suggestions of free/open fonts that could be installed on the server to make
this work...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Are osm ids unique?

2009-01-13 Per discussione D Tucny

2009/1/14 Nop ekkeh...@gmx.de


 Hello!


 Are the ids of osm objects unique?

 A) globally unique

 B) unique only within the type of object, so the same id may occur with
 a way, a node and a relation.

 C) unique only within the type of object, but with non-intersecting
 numbering schemes


 According to the wiki it is B) [1]

 In my data processing I have so far assumed A) and never encountered a
 problem.


 What are the facts?


B is the case...

e.g.
http://www.openstreetmap.org/browse/way/1000
http://www.openstreetmap.org/browse/node/1000

You may not have encountered a problem with assuming A in a limited dataset
as the 'current' value for ways is significantly smaller than for nodes and
the current value for relations is significantly smaller than for ways due
to there being a lot more ways than relations and a lot more nodes than
ways...
From http://www.openstreetmap.org/stats/data_stats.html:
Number of nodes296115165 Number of ways24186209 Number of relations53679
d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [talk-ph] Ensuring data integrity (was: Re: excellent work in subic and ormoc)

2009-01-12 Per discussione D Tucny

It's a very difficult issue to address...

It's important that people are aware of what data sources are valid/allowed
and what are not...

It's also very important I'd say that potential new sources of data are
detailed, documented and reviewed prior to any import to ensure that they
are compatible...

But, these don't help if someone isn't aware, hasn't asked for third party
review of imported data, or, which I'm sure isn't the case here, but, could
happen, if someone conciously makes the decision to do something that isn't
allowed... In those cases potentially unclean data can make it into OSM, and
then it could be very difficult to identify...

The only thing I can see that can help is through a strong community
welcoming newcomers and making sure they are aware of 'the rules' and
helping them do 'the right thing', which osm-ph is already working
towards...

It's still difficult though, and I guess the only 'solution' is for
individuals to review edits and in the event that something looks
suspicious, contact the editing user to find out what their data source
was... Obviously, this is also helped by a strong community :)

So, if you see someone new editing in an area that interests you (obviously
easier to spot in JOSM thanks to the user viewing panel), drop them a
message, welcome them (to osm/your area) introduce them to the wiki pages,
the lists etc, check their edits and give them feedback/assistance,
especially if you see any problems such as unjoined ways, misspelt tag
names, accidental modifications etc... Help them become a productive member
of the community...

d

2009/1/12 maning sambale emmanuel.samb...@gmail.com

 I hope this gets sorted the issue on subic/olongapo, but a bigger
 issue was raised.

 How de ensure data integrity?  In a wiki, you just can't  (100%).  But
 we have to find ways to minimize this.



 On Mon, Jan 12, 2009 at 3:21 PM, maning sambale
 emmanuel.samb...@gmail.com wrote:
  Hi,
 
  The respective mapper is sorting-out his/her edits around subic/olongapo
 area.
 
  cheers,
  maning
 
  On Mon, Jan 12, 2009 at 1:34 PM, maning sambale
  emmanuel.samb...@gmail.com wrote:
  In the meantime, please give the respective contributors the benefit
  of the doubt ;)
 
 
  On Mon, Jan 12, 2009 at 1:28 PM, maning sambale
  emmanuel.samb...@gmail.com wrote:
  I will communicate this to the respective mappers.
 
 
 
  On Mon, Jan 12, 2009 at 12:59 PM, D Tucny d...@tucny.com wrote:
  2009/1/12 D Tucny d...@tucny.com
 
  2009/1/12 maning sambale emmanuel.samb...@gmail.com
 
  Just found excellent updates in two areas:
 
  Subic/Olongapo:
 
 
 http://www.openstreetmap.org/?lat=14.8266lon=120.2912zoom=14layers=0B00FTF
 
  It looks like Olongapo is pretty much covered.  The editor is Deck
  Antonio.
  @ Deck are you on this list?  Great work!  May I know your data
  source?  AFAIK, there are no high-res sat in that area.
  Is this really entirely on gpx?
  http://www.openstreetmap.org/user/Deck%20Antonio/traces/290144
  Wow!
 
  I'm very concerned about that to be honest... The GPX file isn't from
 a
  GPS by the looks of it, it's created by an application called
 ExpertGPS,
  and, contained within it are panaramio points and descriptions of
 paths and
  polygons, which together suggest that potentially it was originally a
 google
  earth exported kml that has been converted with ExpertGPS to a GPX
 file...
  Google does have high res views of the area... If you download that
 GPX file
  and open it in google earth, you'll see that the track almost exactly
  followings the road layout and that buildings and areas are an exact
 match
  to the google imagery... this is BAD...
 
  Much of the area was done by user 'Rally', notes made on nodes and
 ways
  as...
  contributor='Waypointsdotph; Rally de Leon'
  source='Rally de Leon pre-aligned GPS Trackmaker file'
 
  So, it appears that that data is largely imported from another source
 too,
  and there is detail in there that can't be attributed to that user's
  uploaded tracks or usable aerial imagery... In fact, certain features
 are
  reproduced in such detail, considering there positions, that it would
 be
  very unlikely that they could have been produced without aerial
 imagery,
  and, infact, seems to effectively match the available google
 imagery...
 
  I'm sorry to say, but, I think all this data will probably have to be
  removed unless a valid source can be documented...
 
  d
 
 
 
 
  --
  cheers,
  maning
  --
  Freedom is still the most radical idea of all -N.Branden
  wiki: http://esambale.wikispaces.com/
  blog: http://epsg4253.wordpress.com/
  --
 
 
 
 
  --
  cheers,
  maning
  --
  Freedom is still the most radical idea of all -N.Branden
  wiki: http://esambale.wikispaces.com/
  blog: http://epsg4253.wordpress.com

Re: [talk-ph] [PH-Cyberview] Fwd: Presenters needed for APRICOT 2009

2009-01-08 Per discussione D Tucny

I think they are looking from presentations on a different type of routing
than OSM can provide :)

Technology developments is an area that OSM could potentially fit into, but,
as of right now, OSM in the Philippines in still working heavily on data
gathering, in the next couple of years as mapping effort accelerates and the
data set becomes more comprehensive, I'd hope to see people in the
Philippines coming up with some innovative and generally cool ways of using
the OSM data to do things that were not possible without open geodata as is
happening in countries with already reasonably complete data...

I'd agree that 1 presentation offer within the Philippines would be
disappointing, but, I can't help but wonder if this is not indicative of a
lack of awareness of the conference by networking professionals in the
Philippines... I'm not based in the Philippines, but, I am in Asia and I'd
never heard of it before...

d

2009/1/9 maning sambale emmanuel.samb...@gmail.com

 I'm sending to the list.  Do we fit in here?

 On Fri, Jan 9, 2009 at 9:56 AM,  pbvillaflo...@smart.com.ph wrote:
 
 
  I wonder if presenting OSM might be a good idea
 
 
  -- Forwarded message --
  From: Philip Smith p...@cisco.com
  Date: Thu, Jan 8, 2009 at 3:48 PM
  Subject: Re: [PHNOG] Presenters needed for APRICOT 2009
  To: PHNOG Mailing-list ph...@phopenix.net
 
 
  And just to follow up on Anna's message below, to be blunt we don't have
  a single offer of presentation from anyone in the Philippines. Apart
  from being very disappointing, this is most unusual for any APRICOT, as
  the hosting country usually contributes a good portion of the content.
 
  There are still a few speaking slots available. If you want to present
  at APRICOT, please submit your presentation as soon as possible!
 
  Start at: http://apricot2009.net/call_for_papers.html
 
  Thanks!
 
  philip
  --
 
  Anna Mulingbayan said the following on 6/1/09 11:49:
  Hello everyone,
 
 
  There are still some speaking slots available for APRICOT 2009, the
  draft session themes include:
 
  - Internet Exchange Points
  - Routing
  - DNS
  - Technology developments
 
  This is your chance to showcase what we have in the Philippines. If you
  or anyone you know is interested, just drop me an email.
 
 
  Maraming salamat po!
 
 
  Regards
  Anna
 
 
  
 
 
  
 
 
 
  The PhilMusic Podcast - Listen now!
  http://philmusic.com/podcast
 
  Yahoo! Groups Links
 
  * To visit your group on the web, go to:
 http://groups.yahoo.com/group/ph-cyberview/
 
  * Your email settings:
 Individual Email | Traditional
 
  * To change settings online go to:
 http://groups.yahoo.com/group/ph-cyberview/join
 (Yahoo! ID required)
 
  * To change settings via email:
 mailto:ph-cyberview-dig...@yahoogroups.com
 mailto:ph-cyberview-fullfeatu...@yahoogroups.com
 
  * To unsubscribe from this group, send an email to:
 ph-cyberview-unsubscr...@yahoogroups.com
 
  * Your use of Yahoo! Groups is subject to:
 http://docs.yahoo.com/info/terms/
 
 
  This communication is intended solely for the use of the addressee and
 authorized recipients.  It may contain confidential or legally privileged
 information and is subject to the conditions in
 http://www.smart.com.ph/disclaimer.
 



 --
 cheers,
 maning
 --
 Freedom is still the most radical idea of all -N.Branden
 wiki: http://esambale.wikispaces.com/
 blog: http://epsg4253.wordpress.com/
 --

 ___
 talk-ph mailing list
 talk-ph@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-ph

___
talk-ph mailing list
talk-ph@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ph

Re: [OSM-talk] [Tilesathome] Large Maplint files in USA

2009-01-06 Per discussione D Tucny

2009/1/7 David Lynch djly...@gmail.com

 There's a bulk import happening of data in Massachusetts, USA, and
 Maplint is flagging every single node with not-in-map-features because
 of the attribution tag applied to these nodes (see

 http://server.tah.openstreetmap.org/Browse/?layer=maplintz=12x=1239y=1518
 for an example.) This causes Inkscape to use enormous amounts of
 memory when rendering these tiles -- last night, I had a render fail
 because the Inkscape processes rendering z12 and z13 managed to fill
 all 6 GB of RAM+swap on my system.

 Is this a big enough problem to worry about, when Maplint is doing
 what it's supposed to do?


Interestingly, the tags for different features are different...

Building way:
source=MassGIS Buildings (http://www.mass.gov/mgis/lidarbuildingfp2d.htm)

Building nodes:
no tags

Road way:
source=massgis_import_v0.1_20071009093301
attribution=Office of Geographic and Environmental Information (MassGIS)
massgis:way_id=id

Road node:
source=massgis_import_v0.1_20071009093301
attribution=Office of Geographic and Environmental Information (MassGIS)
(sometimes has created_by=JOSM, sometimes not)


POI node (Fire station):
attribution=Office of Geographic and Environmental Information (MassGIS),
Massachusetts Emergency Management Agency
source_url=http://mass.gov/mgis/firestations.htm

It looks like it's only the buildings being uploaded at the moment, and they
don't appear to have anything that should upset maplint...

The roads appear to have been there since October 2007, though in addition
to the tag issues mentioned, there is some nasty overlapping on bits I've
seen of objects with different 'source' dates...

I think it would be nicer if the road ways were modified to move the
attribution content to the source tag and the current source string to a
note/created_by tag... But... it's been like this for over a year...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Which entry level budget garmin

2009/1/6 Joseph Scanlan n7...@arrl.net

 On Mon, 5 Jan 2009, D Tucny wrote:

  What sort of control do you have over the tracklogging with the 760?


 None.  I got mine before I got interested in OSM.  I'm tempted to get an
 eTrex or something for mapping.


I have the 60CSx, there are some things that could be improved, it's not
perfect, but, it does the job and is pretty rugged...



  Still, expensive...


 costco.com (here in the US) had a good price for the nuvi 760 when I got
 mine.  Even then, you should be able to spend less to get a better GPS for
 OSM mapping.


I already have the 60CSx, what I'm looking for now is something for car
navigation, but, that can also store tracks, I'd prefer to have a single in
car unit rather than a nest of wires and a pile of electrical devices,
though it may come to that :) (anyone know of any pure loggers that can be
powered off a 12v car supply and automatically power up and start logging
when that power supply is turned on? ;))

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Which entry level budget garmin

2009/1/5 Erik Johansson e...@kth.se

 On Mon, Jan 5, 2009 at 2:22 PM, D Tucny d...@tucny.com wrote:
  the 200
  series models that are available are expensive enough (the 205 being
  equivalent to 215 British pounds, amazon US price of $136 equivalent to
 93
  pounds),

 Wonder if that has to do with cost of topomaps? They are at least
 infinitive number of times more expensive in the UK than in the US.


Well, I'm not in the UK, I'm in Asia, I was just using pounds to allow for
comparison... Also, the garmin car navigation devices I've seen here have
been limited to street data, no topo data... That said, UK pricing for
Garmin devices did seem to be considerably higher than US pricing too when I
last looked, but, many, especially technology, imports to the UK tend be
priced at around the same number of pounds as dollars, if not more, even
when there were two dollars to the pound :(...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Which entry level budget garmin

2009/1/5 Tanveer Singh tanveer1...@gmail.com

 I am getting a garmin in car unit($200)
 Needless to day the following two functionalities are needed
 1. Read OSM maps(all nuvi can read from SD card)
 2. Write gpx data with altitude and timestamp info

 The second point has gotten me stumped a bit, and I am torn between 3
 models
 205, 260 and 265T.
 the 205 is the cheapest, and apparently some sites say I cannot dump
 GPX tracks to SD card. Is it true?
 Moreover I want to know if there is an auto option for dumping tracks.
 I don't want it to dump tracks every second or so(which causes points
 to be dumped even when stationary).

 Are there any users here of the 205?
 What is the longest log you have dumped?

 I do a lot of mountain roads through foliage, will the nuvi 205 have
 problem getting signal in trees and all, if so what else should I be
 looking at.

 The budget - Lower the better!



PS: I chose garmin because OSM-garmin is the least painful and most doable.


Hi,

Point 1 should be easy enough to do with all 3 models thanks to the tools
available (mkgmap and osm2mp)...

Point 2 is indeed a difficult one... There are certain models in the 200
series where there was apparently the functionality to save tracklogs at one
point by enabling a debug mode, this was apparently removed in later
versions of firmware, but, there are some sites giving details of how you
can revert these specific models back to previous firmware where this
functionality was still present...
I contacted Garmin about this recently as I too am in the market for an in
car unit for navigation and will only buy one that will also allow for
saving tracklogs...

My specific question was:
Hi, I currently have a Garmin GPSMAP 60CSx which I think is great for most
things I use it for, however, I'm looking to get a separate unit for the car
and want to get another Garmin unit, so I'm looking at the nuvi's. One of
the features I like with the 60CSx and feel important to have in whichever
unit I choose is the option to enable trip/track logging to the MicroSD card
which I can then transfer to the computer to analyze. Reading through the
available documentation on your site I can't find information about which
nuvi units support this functionality, so my question is, which, if any,
nuvis allow saving of tracking information? Preferably to a removable
storage card as GPX, in the same way as the 60CSx, as I wouldn't want to
loose information at 1 points which could be a problem if only internal
memory was used.

The response I received from Garmin was:
Thank you for contacting Garmin International.


There are several units that may fit your purpose:

nuvi 500 (you get to see 1:100,000 scale Topo Maps)

nuvi 775T

nuvi 765T

nuvi 755T

  With Best Regards,

snip

Product Support Specialist

Automotive Team

Garmin International
Unfortunately, where I am, none of these models are available, the 200
series models that are available are expensive enough (the 205 being
equivalent to 215 British pounds, amazon US price of $136 equivalent to 93
pounds), the nearest model, a 700 series, but, not a 5 suffix model so
presumably not suitable either is more than double the price (equivalent of
550 British pounds, amazon US price of $250 equivalent to 172 pounds)... So,
for here, there is apparently no model that fits the bill and if there was,
it would likely be too expensive, the lack of local language support makes
an import not practical...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSMA rendering incorrectly

Hi,

In what way did it look not correct? I've just looked now, and it looked
fine, but, I probably looked just after you'd fixed it...

d

2009/1/5 Thomas Wagner wag...@ze.tum.de

 After doing some experimentation, I found, that after splitting the
 feature or editing some of its nodes they are rendered correctly when I
 send a new render request via tah.

 But I still would like to know, what causes the problem.

 Cheers
 Thomas

  Hi.
 
  I am experiencing problems with osma renderer: although the nodes in
  edit mode are correct, osma simplifies the roads and feautures during
  rendering., so that the map is not correct:
 
  e.g. Malawi, M1 south east of Lilongwe:
 
 http://www.openstreetmap.org/?lat=-14.1854lon=34.1314zoom=12layers=0B00FTF
 
  Forced new rendering does not help :-(
 
  Any idea how to resolve this problem??
 
  Thanks
  Thomas
 
 
 
 
 
  ___
  talk mailing list
  talk@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk
 


 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Which entry level budget garmin

2009/1/5 Joseph Scanlan n7...@arrl.net

 On Mon, 5 Jan 2009, D Tucny wrote:

  The response I received from Garmin was:
 Thank you for contacting Garmin International.

 There are several units that may fit your purpose:

 nuvi 500 (you get to see 1:100,000 scale Topo Maps)
 nuvi 775T
 nuvi 765T
 nuvi 755T


 Interesting.  I'm using a nuvi 760.

 What I do is connect the 760 to my computer with a USB cable and transfer
 nuviCurrent.gpx to my hard drive.  nuviCurrent.gpx works as-is in JOSM but I
 have to hand edit it to remove Garmin's data if I want to upload my tracks
 to the OSM servers.

 This might work for the less expensize nuvis but I have to admit it is a
 little awkward.


Interesting indeed...

http://www.geobuddy.com/gps-receivers/Garmin-nuvi-760.asp lists the active
tracklog capacity as 9 track points...
and
http://www.travelbygps.com/articles/nuvi_760.php mentions that only the 700
series get track logging, which seems to be confirmed by
http://www.geobuddy.com/gps-receivers/garmin-geocaching-software.asp...

What sort of control do you have over the tracklogging with the 760? If it
allows 1 point per second, then 9 track points works out at 27hours,
better than the 1 limit of the active tracklog in the handheld units
which works out at 2hrs 46, but, the ones with external storage do allow for
as many points as will fit on the flash card...

Still, expensive...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Which entry level budget garmin

2009/1/6 Tanveer Singh tanveer1...@gmail.com

 On Tue, Jan 6, 2009 at 12:05 AM, Ulf Lamping ulf.lamp...@googlemail.com
 wrote:

  In the end it might be easier (and not even a lot more expensive) to buy
 a
  cheap car navi (Garmin 200W ~100EUR) for navigation and a cheap GPS
 logger
  (Wintec WBT 201 ~ 100EUR) or Outdoor GPS (Garmin eTrex ~150 EUR) for
  logging.
 
  To me this is far more useful than having one device doing nothing right
 ;-)
 
  Regards, ULFL
 

 If you use track type=off road and turn off snap to road in settings,
 it will not snap track to map.


I think ULFL's point was that with his Zumo there isn't such a configuration
option, so while it does save track logs, he's not confident that they are
acceptable due to the potential that it is just snapping to road and as
such, copying the copywrited built in maps rather than saving tracks based
on the GPS recorded position... A nuvi could have this problem too if this
is not configurable...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Invisible coastline errors in Potlatch

2008-12-31 Per discussione D Tucny

2009/1/1 Cartinus carti...@xs4all.nl

 On Wednesday 31 December 2008 18:40:18 Peter Miller wrote:
  Dodgy circular ways
  ---
 
  There are a number of islands off the Swedish coast that are showing
  up as errors:
 
 http://tile.openstreetmap.nl/coastlines.html?zoom=16lat=57.80195lon=11.66
 246layers=B00
 
  If one switches to a OSM view
  (
 http://www.openstreetmap.org/?zoom=16lat=57.80195lon=11.66246layers=B00
  ) one can edit them. Using 'h' I can see that they haven't been
  touched for months, however if I click on them the tagging looks fine
  and the way is shown as circular.
 
  Here is the history of one of them:
  http://www.openstreetmap.org/browse/way/25610508/history
 
  Notice that the way appears to be a triangle, but that the way has
  four points on it.
 
  If it does have an extra segment in the way then why does it show up
  as a circular way in Potlatch? The simples thing will probably be to
  delete them and recreate them but I though it was worth pointing it
  out first.

 With any circular way the first and the last nodes are the same. So to
 define
 a triangle you get four nodes in the xml.


But, the problem is that often with the coastline imports, one of those
nodes is a duplicate... i.e. there are really 4 nodes, but the last one is
at the same point as the first...



 Those Swedish islands show up as errors because they are too small.
 Anything
 with a diameter of less than approximately 10 meter shows up as an error.

 Are you sure? or is it the previous problem?

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Invisible coastline errors in Potlatch

2008-12-31 Per discussione D Tucny

2009/1/1 Cartinus carti...@xs4all.nl

 On Wednesday 31 December 2008 20:29:50 D Tucny wrote:
  2009/1/1 Cartinus carti...@xs4all.nl
   On Wednesday 31 December 2008 18:40:18 Peter Miller wrote:
Here is the history of one of them:
http://www.openstreetmap.org/browse/way/25610508/history
 
  Are you sure? or is it the previous problem?

 Try that hyperlink, then you'll know the answer too.


It's true! coastline checker bug... :( Sorry for doubting you...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Talk-ca] Northern lights

2008/12/31 michc...@gmail.com

 On Dec 29, 2008 10:41am, Jochen Topf joc...@remote.org wrote:
  On Mon, Dec 29, 2008 at 03:08:36PM +, michc...@gmail.com wrote:
 
   There just was a discussion on dev about a single way with 40.000
 nodes.
 
  
 
   That is far too long to be able to handle it with current software and
 
  
 
   makes lots of problems. Are you maybe referring to that? Ways should
 not
 
  
 
   have more than 1000 nodes or so.
 
  
 
  
 
   Yes we are. The current ways we are talking about may have more than 40
 
   000 nodes. I would like to delete them and replace them by chopping the
 
   ways.
 
  
 
   Do you known how I could delete the current ones at once. I thought
 about
 
   something like: SELECT boundary FROM ways WHERE
 
   (boundary='administrative' AND admin_level=4 AND source='geobase'). The
 
   number we should get is 503 ways.
 
 
 
  When you uploaded those ways you should have gotten the new way_id. If
 
  you didn't record this but remember on which day you did the upload you
 
  can download the right daily or hourly diff (from
 
  http://planet.openstreetmap.org/) and find the IDs in there. (And record
 
  the IDs the next time you do a bulk upload for cases like this.)
 
 

 Ok. I found the IDs of the ways I would like to delete. What do I do next
 to retrieve them and remove them. Thanks.

 Michel


One way to do it would be to script a request to
http://api.openstreetmap.org/api/0.5/way/wayid for each wayid, stripping
the ?xml?, osm and /osm tags out and concatenating into a single
file...

Parse the resulting file extracting node IDs, and add lines similar to
node id=nodeid lat='0' lon='0' visible='false' / to the beginning of
the file...

If you want to/can use JOSM to remove them, when complete, add back the
?xml and osm tag at the top, the /osm tag at the bottom and replace all
instances of visible='true' with visible='false', load into JOSM and hit
upload...

Otherwise, you'll probably need to use the bulk import script, for this,
you'd add ?xml, osmChange and delete tags at the top and /delete and
/osmChange at the bottom, then feed it through the bulk import script...

I hope that helps... It's quite easily scriptable, though perhaps someone
has a premade bulk-delete script already...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Talk-ca] Northern lights

2008/12/31 Jochen Topf joc...@remote.org

 On Wed, Dec 31, 2008 at 03:26:26AM +, michc...@gmail.com wrote:
  Ok. I found the IDs of the ways I would like to delete. What do I do next
  to retrieve them and remove them. Thanks.

 http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.5


In addition to what I wrote before... the use of the /full modifier (which I
had either not noticed before or forgotten about, thanks Jochen) when
fetching the ways would allow fetching of the nodes too, though you would
likely need to sort the resulting file before being able to use it...
Actually, as you don't really need the original nodes to delete them it
might not be so useful in this case...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Map Update

2008/12/31 Andre Schoonbee andre...@iway.na

 Hi All

 First, seasonal greetings!

 I have a few questions:

 1) I have uploaded roads data using JOSM. This now is appearing as normal
 lines and not as per the classified roads. I like Mekaartor also, and can
 want to upload the rest of the roads. Am I using the correct process,
 because some roads are new and some is a change of the existing roads.
 I download the respective area, add my data and delete on my pc what seems
 to be incorrect, then upload again.


You process appears correct...



 2) I also would like to add more parameters for the roads, like average
 travel speed, speed limit, etc. could it be done? The reason why I want to
 add this is to be used in our routing component, eventually to determine
 also average travel time.


You can add as many parameters as you want...

Check out http://wiki.openstreetmap.org/wiki/Map_Features for ideas, if you
can't find a way on there to represent a certain parameter, look at proposed
features too, if there is no evidence that that parameter has been captured
before, feel free to propose a new one... While you don't have to propose a
new feature to tag things, as tagging is open, it's kind of nice for the
community if tags are documented so that people can acheive some level of
standard tagging of the same features...

And specifically, for the speed limit,
http://wiki.openstreetmap.org/wiki/Key:maxspeed (from the Restrictions
section of the Map Features page)

Average travel speed it a tricky one, it can vary dramatically based on mode
of transport, time of day, day of week and season, there has been discussion
in the past about using the GPS tracks to be able to calculate figures for
this, but, it would take some considerable effort and lots of tracks for
individual routes... As such, I don't think much progress has been made on
it and I believe people have been typically using formulas that work with
the maxspeed, road type and other magic variables to attempt to approximate
average travel speed...

I hope this helps :)

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [Talk-ca] [OSM-talk] Northern lights

2008/12/31 michc...@gmail.com

 On Dec 29, 2008 10:41am, Jochen Topf joc...@remote.org wrote:
  On Mon, Dec 29, 2008 at 03:08:36PM +, michc...@gmail.com wrote:
 
   There just was a discussion on dev about a single way with 40.000
 nodes.
 
  
 
   That is far too long to be able to handle it with current software and
 
  
 
   makes lots of problems. Are you maybe referring to that? Ways should
 not
 
  
 
   have more than 1000 nodes or so.
 
  
 
  
 
   Yes we are. The current ways we are talking about may have more than 40
 
   000 nodes. I would like to delete them and replace them by chopping the
 
   ways.
 
  
 
   Do you known how I could delete the current ones at once. I thought
 about
 
   something like: SELECT boundary FROM ways WHERE
 
   (boundary='administrative' AND admin_level=4 AND source='geobase'). The
 
   number we should get is 503 ways.
 
 
 
  When you uploaded those ways you should have gotten the new way_id. If
 
  you didn't record this but remember on which day you did the upload you
 
  can download the right daily or hourly diff (from
 
  http://planet.openstreetmap.org/) and find the IDs in there. (And record
 
  the IDs the next time you do a bulk upload for cases like this.)
 
 

 Ok. I found the IDs of the ways I would like to delete. What do I do next
 to retrieve them and remove them. Thanks.

 Michel


One way to do it would be to script a request to
http://api.openstreetmap.org/api/0.5/way/wayid for each wayid, stripping
the ?xml?, osm and /osm tags out and concatenating into a single
file...

Parse the resulting file extracting node IDs, and add lines similar to
node id=nodeid lat='0' lon='0' visible='false' / to the beginning of
the file...

If you want to/can use JOSM to remove them, when complete, add back the
?xml and osm tag at the top, the /osm tag at the bottom and replace all
instances of visible='true' with visible='false', load into JOSM and hit
upload...

Otherwise, you'll probably need to use the bulk import script, for this,
you'd add ?xml, osmChange and delete tags at the top and /delete and
/osmChange at the bottom, then feed it through the bulk import script...

I hope that helps... It's quite easily scriptable, though perhaps someone
has a premade bulk-delete script already...

d
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] [OSM-talk] Northern lights

2008/12/31 Jochen Topf joc...@remote.org

 On Wed, Dec 31, 2008 at 03:26:26AM +, michc...@gmail.com wrote:
  Ok. I found the IDs of the ways I would like to delete. What do I do next
  to retrieve them and remove them. Thanks.

 http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.5


In addition to what I wrote before... the use of the /full modifier (which I
had either not noticed before or forgotten about, thanks Jochen) when
fetching the ways would allow fetching of the nodes too, though you would
likely need to sort the resulting file before being able to use it...
Actually, as you don't really need the original nodes to delete them it
might not be so useful in this case...

d
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk] I've added some amenity values to Map Features based on tag usage

2008-12-21 Per discussione D Tucny

2008/12/21 Ed Loach e...@loach.me.uk

 I wrote:
  From that I've so far used
  amenity=dog_bin

 d replied:
  I don't like the sound of that one... Is it for dogs to
  use or where you put your used dogs? :/

 I'm not sure whether this is tongue in cheek, or where you are, but in the
 UK (or at least this bit of it) it is an offence for dog owners not to clean
 up any solid waste that their dogs leave in public areas, punishable by
 fines. To assist with this (some) councils provide bins for such bagged
 waste to save the dog walkers the hassle of carrying it home to get rid of
 it. Not all do, alas, so on my mapping walk yesterday around some local
 meadows I still had to watch where I was walking. And one dog owner who
 walks their dog along our street has been seen bagging up the waste and then
 disposing of the bag in a handy front garden (my stepdaughter spotted her
 once doing so in our garden and took the bag back to her).

 In the area I was in yesterday, and the recreation ground I was looking at,
 the dog bins are more numerous than the litter bins.


I've never heard of them called dog bins before... There was a certain
amount on tongue in cheek in my reply... A waste bin is for putting waste
in, a waste paper basket is for putting waste paper in, a recycling bin is
for putting recycling in, etc... so a dog bin, following the same logic
would be for putting dogs in... Dog insert work meaning excrement bin
would make sense... Or Dog waste bin in a more general sense, or to
generalise even more incase of non-dog pets that may be found, pet waste
bin... Just trying to suggest clear tagging :)

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Indiscrimate layering

2008-12-21 Per discussione D Tucny

2008/12/21 OJ W ojwli...@googlemail.com

 Doesn't layer=-1 mean that something should be 'below' the landuse
 polygons when rendering?  So if you have a river at level=-1 on a
 landuse=farm, then you will never see the river because it's under the
 (default layer=0) ground.

 In fact, I'm surprised the robot didn't automatically add a tunnel=yes
 to the rivers that were tagged layer=-1...  (which would probably be
 valid for those cases where a stream just goes through a pipe to get
 under the road - that could hardly be described as 'a bridge')


I thought landuse was further rendered below everything else... And looking
at it, a waterway at layer=-1 does render on top of landuse in osmarender at
least...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [talk-ph] Trying out Merkaartor

2008/12/20 Eugene Alvin Villar sea...@gmail.com

Hi guys,

After seeing someone using Merkaartor (http://www.merkaartor.org/) to edit
in OSM, I decided to give it a try last night. Before this, I've been
exclusively using Potlatch. Potlatch is a pretty good application and is
definitely the best Flash application I've ever seen but I quickly ran into
one of its limitations while I was doing Eastwood City and Bonifacio High
Street. The limitation is that at the highest zoom level, you cannot place
nodes more accurately: the nodes snap to a 3-pixel grid. This 3-pixel grid
translates to a resolution of almost 3 feet at the latitude I'm working at.
This is more than good enough for roads, but not adequate for buildings.
(I'm kinda OC [obsessive-compulsive, slang in Philippine English] when
mapping the details of buildings, and this limitation prevented me from
making nice right angles of small idented corners of buildings. See this
view of Bonifacio High Street for example:
http://openstreetmap.org/?lat=14.550474lon=121.0513zoom=18layers=B000FTF)
I asked Richard, Potlatch's creator, about it and he acknowledged this
limitation (our conversation is at the OSM Wiki:
http://wiki.openstreetmap.org/index.php?title=User_talk:Richardoldid=161158#lat.2Flong_resolution_in_Potlatch
).

If you're using Potlatch, then Merkaartor gets some getting used to with
regards to its interface. The workflow is pretty much the same as in JOSM
(another OSM editor): you go to an area, download the data, edit at will,
then upload the changes. I like it because it doesn't have the
aforementioned 3-pixel limitation in, and in addition, it blows up the
Yahoo! map tiles if they're not available in a higher zoom level; Potlatch
just shows Yahoo!'s We're sorry, the data you have requested is
unavailable tiles. (I'm not sure if Merkaartor's behavior is allowed by
Yahoo!'s TOS).

I'll still continue to use Potlatch as a general editing tool since it's
pretty quick and I'm used to it. I'll just bring out Merkaartor if ever I
want some finely wrought detail. :-)

Merkaartor has improved each time I've used it and it's look pretty good
now, but, last time I used it it still seemed somewhat less responsive than
potlatch or JOSM and that was on a reasonably decent PC... On the one I'm on
right now, JOSM struggles so I don't dare try merkaartor...

JOSM also blows up the Yahoo imagery in the same way, not sure if it only
applies where there is higher level zoom data available or if the function
just can't cope with the boundaries between high quality imagery and low
quality imagery...

One of the other new features in JOSM that I'm not sure if Merkaartor has,
but, is quite useful for some buildings is the Orthogonalize tool, it only
works correctly if you have the projection setting set to Mercator instead
of the default EPSG:4326 but will warn you if that's not the case... It's an
advancement on the previous align in rectangle tool as it adjusts all
corners to 90 degrees, even on objects with more complex shapes (as long as
all corners are 90 degrees)... Something that could work well with the
buildings on Bonifacio High Street which are nice and orthoganal (though not
well at all with those of The Fort strip or Serendra)...

For multiple buildings that are the same shape JOSMs copy and paste
functionality and rotate functionality can also save time and effort, though
a flip vertically or horizontally function would be a useful addition for
'mirrored' buildings...

As you mentioned about Potlatch and it's snap to though, JOSM also has
snapping, yes, you can zoom in to entire screen = 1m to get around that,
but, it can be frustrating when JOSMs guide as to what will happen when you
create a node tells you it won't snap to another way, but, when you click 4
nearby ways all get pulled together, at least you can easily undo just that
last click, select the previous node and try again though and I seem to
recall there's some key stroke which you can use with the click to prevent
snapping, but, I forget...

d
___
talk-ph mailing list
talk-ph@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ph

Re: [OSM-talk] Indiscrimate layering

2008/12/21 Sven Rautenberg s...@rtbg.de

 Elena of Valhalla schrieb:
  On Sat, Dec 20, 2008 at 1:17 AM, Sven Rautenberg s...@rtbg.de wrote:
  Please reconsider.
 
  I hate it when I see rivers, streams etc. illogically marked as
  layer=-1. There is no reason to do so, because a river usually is at the
  top of the surface, and that is no layer or layer=0.
 
  not so true everywhere: in mountain areas rivers are usually at the
  bottom of valleys,

 The bottom of a valley is layer=0.

  and I've seen many small rivers covered and
  practically brought underground in urban areas.

 These streams should be tagged tunnel=yes, layer=-1.

  as a guideline, i usually mark the road +1 if it rises to become a
  bridge, but 0 and the river -1 if the river is lower than the ground
  where most of the road is

 If you come across an existing stream which has no layer tag, do you add
 layer=-1 to the whole stream and then check the whole stream if your
 change may conflict e.g. with a tunnel which is already at layer=-1? I
 don't think so.

 Tagging a part of a way with a non-default layer does not mean anything
 about it's elevation. It is all relative, but it is a good idea to
 assume natural surface level to be layer=0 in most cases.

 The stream therefore is the natural surface wherever its water flows.
 The bridge is above the water, so it is layer=1. And it is less
 dangerous when just tagging the bridge compared to tagging the whole
 stream.


I also tag many waterways around here as layer=-1, because that's what they
are... thank god they aren't layer=0 or the place would be under water! The
waterways are below the surrounding land, hence the water stays in them,
below the surrounding land... the roads stay on the surround land hence they
stay dry, except when it rains, but...

I will note that around here there are 100s of manmade waterways with roads
passing over most of them with no obvious bridges and no increase in
elevation... There are no instances of roads going under these waterways,
which helps... Where there is an obvious bridge, it is tagged as such...

Layers, like speed, are relative with 0 being default and as such, normal...
so... I personally agree with David and Elena above... If you've mapping
something that is mostly below the majority of other features, make it -1,
if it's mostly above, make it +1, or whichever valid value you choose... For
me... the main road network is layer 0 with anything running over it as a
positive and anything running under it a negative...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Some more shops and amenities for the map features page ...

2008/12/21 Ulf Lamping ulf.lamp...@googlemail.com

 Hi!

 Again, I've added some more shop and amenity values to the map features
 page (http://wiki.openstreetmap.org/index.php/Map_Features), derived
 from the tagwatch usage statistics
 (http://tagwatch.stoecker.eu/Europe/En/index.html).

 I've added the following values - with the current tagwatch usage count:

 shop=
 computer 115
 department_store 133
 electronics 211
 garden_centre 127
 optician 100
 shoes 140

 amenity=
 dentist 133
 doctors 430
 embassy 150
 hunting_stand 501
 signpost 444


 It seemed that for these values there were no real rivals with equal
 meaning (maybe except for amenity=doctor used 160 times).

 If you don't like these values: don't shoot the messenger, the values
 are just in use ...


Not shooting the messenger ;) this is to the wider audience...

What makes an optician's a shop whereas a dentist is an amenity? NHS?
Opticians selling sunglasses?

Is a signpost an amenity or a highway feature? I'd go with highway
feature...

And embassies... I'm not sure amenity fits here either... perhaps a wider
goverment related key would be more suitable?

The rest seem 'right' to me ;)

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Some more shops and amenities for the map features page ...

2008/12/21 Nic Roets nro...@gmail.com

 I'm just a little bit disappointed that tag watch does not yet cover
 the rest of the world.

 For example, in South Africa we already mapped 40 shop=shoes. But no
 doctor(s) yet !


http://tagwatch.stoecker.eu/world.html ?

The name non-US suggests to me it covers all but the US (though there is
quite a bit of tiger data listed in there)...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] I've added some amenity values to Map Features based on tag usage

2008/12/21 Ed Loach e...@loach.me.uk

 From that I've so far used
 amenity=dog_bin


I don't like the sound of that one... Is it for dogs to use or where you put
your used dogs? :/

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is OSM Mapper ready for 0.6? (was Re: DisablePotlatch finally)

2008/12/18 Shaun McDonald sh...@shaunmcdonald.me.uk


 On 18 Dec 2008, at 08:56, maning sambale wrote:

  In short:
 
  Mappers need not worry about changing mapping habits.  Editing is the
  way it is (unlike the transition from API 0.4 to 0.5!), you're just
  encourage to explain your edit session via changeset comments
 
  This is what I usually do:
  1. Download a manageable chunk via OSMXAPI.

 Is the OSMXAPI ready to return version numbers? [For devs to answer]

 
  2. Edit via JOSM for a full 4-5 hours.
  3. Then upload via my dial-up (10 kbps) connection.
  4. Sleep.
 
  What if someone edited a few ways?  Does it invalidate my whole
  changeset/edit session? Or just the modified node/way/relation?

 It will invalidate just the modified node/way/relation.
 With JOSM in 0.6 there will be diff uploads, which means that all the
 changes are sent at one time. This does mean that the whole change
 will be rejected, if one node has been modified before you have
 uploaded. As the upload is done as a single request, less bandwidth
 hence time will be required. I don't know what the speedup is. The
 speedup is likely to depend on the network connection.


If the API specifies which particular objects in the change were a problem,
it would be good if JOSM gave the option of downloading just those objects
and performing conflict resolution rather than just failing... Not got a
clue how hard that would be to implement though...

The speedup will be pretty sizable for high latency links such as many of
those in asia when transfering more than a few modification... I'd guess
Maning being on a dialup link in asia will probably see a pretty decent
speed up as compression should take care of most of the size of the change
and being sent in one go should remove most of the time taken in
establishing new connections...

With an rtt of 250ms, creating 100 nodes in 0.5 would take at least 750ms
per node or 75 seconds for the 100 nodes at one connection per node plus
transfer time... in 0.6 this should be reduced to 3 connections, so 2.25
seconds plus transfer time... I'd guess Maning's rtt is somewhat higher than
250ms though in which case he'd save even more, as I will with my best case
rtt of 320ms to the API...

Of course this assumes that JOSM isn't reusing connections, which I think is
true and it also assumes that I'm not making silly mistakes or missing
things...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] GeoBase nodes import

2008/12/18 Tom Hughes t...@compton.nu


  So far, it looks like the majority of the country would be able to
  accept a full import of everything... except the roads. .. it's only 10
  or so tiles that nothing would be imported (just nodes), and less than
  100 where only roads would be omitted.  (there are 12,539 tiles in
  Canada) (.5x.25 degrees) - something like that... the actual breakdown
  will (should) be posted on the wiki.

 So this is mostly only about the roads, but in a lot of ways people
 would probably consider them the most important feature, so if we don't
 get any roads imported without them having to be traced over then we've
 only gained a fairly limited amount.

 To be honest most of this is obviously up to you guys as you're the ones
 that will have to work with it. My main concern is what impact whatever
 scheme you choose will have on the server infrastructure and data
 storage requirements, which is why I have concerns about creating tens
 of millions of nodes which have many duplicated tags or which will wind
 up never being used and will just be deleted again.


If it's only 10 tiles of 12539, why bother with importing anything at all
for those 10 tiles automatically and instead have those areas manually
merged in?

For the 100 where roads would be omitted, surely again a manual merge of
that road data for those 100 would be the best solution... Then, as Tom
says, you only have to share the OSM files for the data to the people who
are taking responsibility for massaging the data in rather than putting in
lots of nodes with all the way names attached, which appart from using up
lots of space, would be a pain in the bum to connect up and in the event
that roads are already there, would you want a stack of unconnected nodes
all over the place that need someone to manually hunt down and delete?

I could see having a copy object down to lower layer option in JOSM would be
very useful for the manual merging... I know that you can already copy
between layers, but, I think it's either merge the entire layer into the
lower one or copy an object to another layer but not preserving it's
position...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [tagging] Feature Proposal - RFC - (Publisher)

I can see why someone might want to record company offices/businesses in
OSM...

But...

as I mentioned on the proposal talk page, I'm not convinced that a publisher
is an amenity... publisher could be a value for a business/business_type/etc
key which could then be used to record many other types of business, I'm
sure the people who are responsible for some of the micromapping of shopper
areas would like this as they run out of shopping areas and look to hit the
business parks etc...

d

2008/12/18 Charlie Echo openstreet...@coutiere.com

 Well, to be honnest, I don't see the point.

 We could scroll the activities' list of any Yellow Pages company and get
 hundreds of activities. All of them would deserve to be in OSM...
 But how many are useful? Only the ones related to health, food, sport,
 culture, education...

 As nobody will ever buy a paper directly from the publisher, the indication
 is of limited intererest. So let's populate the Kiosks tags in OSM instead
 of Publishers.



 - Mail Original -
 De: Manuel de la Torre mdlto...@gmail.com
 À: talk@openstreetmap.org
 Envoyé: Jeudi 18 Décembre 2008 08:58:34 GMT +01:00 Amsterdam / Berlin /
 Berne / Rome / Stockholm / Vienne
 Objet: [OSM-talk] [tagging] Feature Proposal - RFC - (Publisher)

 Sorry for my fist post. This is my first proposal and I am very new to
 this.

 I am proposing the tag:publisher.

 Intent: To mark the location of a publisher. Could be a magazine,
 newspaper, music, software, book, etc...

 The wiki page of the proposal is at:
 http://wiki.openstreetmap.org/wiki/Proposed_features/Publisher

 I will really appreciate your comments.

 Meme.

 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk

 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Errors or not errors?

2008/12/19 Tomas Straupis tomasstrau...@gmail.com

Hello

While fixing some validation errors I've found an interesting case and
would like to get your opinion on how to deal with it.

There is a school stadium mapped. Stadium has a usual oval and two
starting
tails. It is mapped as leisure|track and validators seem to assume these
have
to be closed areas (which is true in most cases).

http://keepright.ipax.at/report_map.php?ch30=30lat=54.69444lon=25.20876zoom=17requery=requerylayers=0BT
In this example stadium is made up from two ways. In some other
instances
it could be made of one way having an extra line (something like letter
Q).

This kind of mapping is rendered ok in osmarender and garmin map created
with mkgmap but is NOT rendered in mapnik.

Does anybody have any experience dealing with such kind of problems?
Should these stadiums be mapped in a different way or should validators be
updated?

Thank you

P.S. keepright is not the only validator identifying this as an error.

leisure=track is defined as applying to nodes or areas... in this case you
seem to have effectively applied it to linear ways...

By the looks of it, osmarender at least has probably only rendered it
because of it's features to try to correct broken areas...

Adam, who has already replied has mapped one such that the outer boundary of
the track is drawn and a hole drawn on the inner boundary of the track...

I'd suggest that to correct these problems then the area should be turned
into a contiguous area around the perimeter of the track such that the
'tails' have some actual width and are contained in way and area as the main
oval section of track...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [Talk-ca] [OSM-talk] GeoBase nodes import

2008/12/18 Tom Hughes t...@compton.nu


  So far, it looks like the majority of the country would be able to
  accept a full import of everything... except the roads. .. it's only 10
  or so tiles that nothing would be imported (just nodes), and less than
  100 where only roads would be omitted.  (there are 12,539 tiles in
  Canada) (.5x.25 degrees) - something like that... the actual breakdown
  will (should) be posted on the wiki.

 So this is mostly only about the roads, but in a lot of ways people
 would probably consider them the most important feature, so if we don't
 get any roads imported without them having to be traced over then we've
 only gained a fairly limited amount.

 To be honest most of this is obviously up to you guys as you're the ones
 that will have to work with it. My main concern is what impact whatever
 scheme you choose will have on the server infrastructure and data
 storage requirements, which is why I have concerns about creating tens
 of millions of nodes which have many duplicated tags or which will wind
 up never being used and will just be deleted again.


If it's only 10 tiles of 12539, why bother with importing anything at all
for those 10 tiles automatically and instead have those areas manually
merged in?

For the 100 where roads would be omitted, surely again a manual merge of
that road data for those 100 would be the best solution... Then, as Tom
says, you only have to share the OSM files for the data to the people who
are taking responsibility for massaging the data in rather than putting in
lots of nodes with all the way names attached, which appart from using up
lots of space, would be a pain in the bum to connect up and in the event
that roads are already there, would you want a stack of unconnected nodes
all over the place that need someone to manually hunt down and delete?

I could see having a copy object down to lower layer option in JOSM would be
very useful for the manual merging... I know that you can already copy
between layers, but, I think it's either merge the entire layer into the
lower one or copy an object to another layer but not preserving it's
position...

d
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk] caching of landsat/yahoo images

2008-12-17 Per discussione D Tucny

2008/12/17 Roman Neumüller em...@katpatuka.org

 The JOSM plugin lakewalker has the IMHO very nice feature to cache the
 landsat
 tiles it uses for walking a lake into its own folders. I just wonder if
 that
 feature couldn't get extended to generally cache landsat images into a
 folder !?

 If you live in a region were there is no Hires-data available at all you
 *solely*
 have potlatch's flash/yahoo data or josm's landsat data to rely on. But
 you have
 to download the image data over-and-over again whenever you are in the
 same region.

 And: the same idea might apply for potlatch's flash/yahoo image data!
 Wouldn't it be nice to have already downloaded images cached ?!?


I seem to recall there was an issue with caching the yahoo tiles relating to
something along the lines of having them saved to disk is not in accordance
with the permission to use the imagery... or something... Landsat should be
cachable though I guess...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] clearing the remaining coastline issues?

2008-12-17 Per discussione D Tucny

2008/12/17 Peter Miller peter.mil...@itoworld.com


 There are really not that many coastine problems left in OSM. I know
 the view below makes it look really very bad but it is only the east
 and south coasts of the USA that have significant errors left. It
 really doesn't take too long, especially as it is hard to stop! If
 about 5 people gave some time to it then it would all be done in a
 week or so. When the coast is clean the data will be much more useful
 for more purposes.

 Here is a view of what is left.

 http://tile.openstreetmap.nl/coastlines.html?zoom=2lat=52.83478lon=-3.66051layers=B00T

 My personal aim is to have the coastline free of these errors rather
 than the have it accurate. I often leave lots of work for locals to
 do, but I want the coastline to not have broken sections and have
 water on the right etc. Sometime I delete closed sections where the
 vectorisation process was got it all wrong, sometimes I reverse the
 ways to keep water on the right, and there are also linear sections of
 coast that either need to be completed or deleted.

 Can I suggest that people commit to doing different parts of the
 globe. For example someone might say they were doing Australia and the
 islands to the north east of there and also New Zealand.

 I suggest that the USA is dealt with by state. I am happy to work on
 sorting Florida.

 Any other offers? One person could probably sort Europe and Asia in an
 evening! Africa would take about an hour. the USA slightly longer.
 Canada might need two people to sort all the islands to the north.


Your email seem to have overloaded the coastline server :(

An error occurred: FATAL:  connection limit exceeded for non-superusers

  File /var/lib/python-support/python2.4/TileCache/Service.py, line
103, in _load
cache = cache)
  File /var/lib/python-support/python2.4/TileCache/Service.py, line
73, in _loadFromSection
return section_object(section, **objargs)
  File /var/www/oam/tilecache/oam.py, line 10, in __init__
self.db  = psycopg2.connect(dsn)

  File /var/lib/python-support/python2.4/TileCache/Service.py, line
221, in modPythonHandler
host )
  File /var/lib/python-support/python2.4/TileCache/Service.py, line
166, in dispatchRequest
raise TileCacheException(%s\n%s % (self.metadata['exception'],
self.metadata['traceback']))

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [tagging] Feature Proposal - RFC - (Publisher)

2008-12-17 Per discussione D Tucny

2008/12/18 Manuel de la Torre mdlto...@gmail.com



 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk


Erm... Am I missing something?

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Disable Potlatch finally.

2008-12-16 Per discussione D Tucny

2008/12/16 Gert Gremmen g.grem...@cetest.nl

 - upload only on request, not after each and every
  mouse click


I think this would be an improvement, especially if you could view a list of
changes that would be uploaded prior to upload... Though I'm sure others
would feel the opposite... Most of the 'potlatch errors' that I see seem to
be a result of someone clicking on things, possibly wanting to see what a
point is tagged as, but, accidentally moving it or accidentally creating a
node or way... I struggle to see a way that these sort of errors could be
prevented/reduced without making people make a conscious decision about
commiting changes and being able to see what changes they've made...

One thing though that I don't think anyone could argue against would be a
way to get help on all the key strokes etc from within Potlatch... Potlatch
is simple to use to draw features with, but most of it's additional features
seem to be hidden away with no easy way to find them from within Potlatch
itself...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: [OpenStreetMap] GPX Import Failure

2008-12-12 Per discussione D Tucny

2008/12/12 Kenneth Gonsalves law...@au-kbc.org

 On Friday 12 Dec 2008 5:17:24 pm Shoan Motwani wrote:
  I use whereami on Nokia E71. I have uploaded a couple of traces in the
  past and they have updated successfully. But the recent traces are not
  being uploaded and the error is too vague to figure out what is going
  on.

 I use whereami on nokia E71 without problem - please paste the gpx file
 somewhere so we can analyse it


Apologies for hijacking the thread, but, how did people install whereami/get
whereami to work on their phones? I tried on my N78 and it just whinged
about the certificates and refused to run... Does the E71 not care about the
certificates?

Thanks,

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] addressing

2008-12-10 Per discussione D Tucny

2008/12/10 Ed Loach [EMAIL PROTECTED]

   In your country, perhaps. In my country, that's EXACTLY what
  the address is.
  The address is the street and distance from the street's
  starting point, in
  metres.

 What happens if two houses are built facing each other on opposite
 sides of the street? Wouldn't they get assigned the same number? Or
 does someone arbitrarily decide which is closer and increase or
 decrease one of the numbers by 1?


With such a structured system, do you think the planning codes would allow
this? I guess they have to be offset by at least 1m...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] My slippy map

2008/12/9 Bernhard Zwischenbrugger [EMAIL PROTECTED]


  am I right in thinking that you're not restricting  it so that you can
 only view at specific zoom factors but you can also  drag the tiles when
 they're part-way between zooms?


 That's the big problem.
 Google Maps always snaps to a good zoom lavel - but I don't like it very
 much.
 I'm searching for a solution - but have no idea how to solve that.
 The user expects an excellent picture for all zoom levels, but that's not
 possible with raster images.


If between zoom levels, would it give better results if you were to take the
next zoom level in rather than the next zoom level out?

i.e. use zoom 13 tiles shrunk slightly if at an effective zoom 12.5 rather
than zoom 12 tiles stretched slightly...

I guess the downside would be the extra tiles that would need to be
fetched...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] My slippy map - call for testing

2008/12/9 Bernhard Zwischenbrugger [EMAIL PROTECTED]

 Hi

 Just an other slippy map:
 http://lamp2.fhstp.ac.at/~lbz/beispiele/ws2008/oomap4/index.php

 Maybe you like the zoom.


I like the smooth zoom... Unfortunately mouse wheel zooming doesn't appear
to be working for me in Google Chrome... In Firefox it works fine, perhaps a
little slow though, but, not sure if that's due to having a high resolution
mouse wheel and a little slow is better than what happens with the normal
zoom (small scroll down movement makes for zoom out to zoom level 1)...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] addressing - Tower blocks

2008/12/9 Douglas Furlong [EMAIL PROTECTED]

 2008/12/8 SteveC [EMAIL PROTECTED]


 I'd like to throw a quick question in here, now that this is being
 discussed, and people with a much better idea of tagging and related issues
 are reviewing the thread :)

 I live in an area of London that has a massive number of residential tower
 blocks, some having 10 flats, others having over 100.

 What would be the best way of putting in these house numbers, so that they
 can be mapped?

 Linked are two examples where i've put address data in, so that if nothing
 else it is stored, but it's not being drawn which is a pity, and problem
 wouldn't be brought up on a search.


 http://openstreetmap.org/?lat=51.478197lon=-0.110314zoom=18layers=B000FTF(you'll
  need to view the data, as they buildings are not rendered).
 http://openstreetmap.org/?lat=51.53264lon=-0.09008zoom=17layers=B000FTFT

 I'd love to be able to put in the buildings and where possible easily map
 the house number ranges.

 Any idea's?


You'll see that some buildings in that view are showing up... they key
difference between the ones that are showing up and the ones that aren't is
that the ones that are have the building=yes tag... the others don't...
Adding the building tag would allow them to be rendered and recognised as
buildings... In the osmarender layer the numbers would even show up...

The numbering however would be an issue with those there...

The interpolation scheme is specified as being a linear way containing at
least two nodes with numbers... So, for example, on the building that has 1
- 21 Mandela street, the building could be tagged as it is now, but without
the interpolation tag... This should then be rendered in osmarender as 1 -
21 over a solid circle...

Alternatively, if each of the numbers is reachable from the street from one
end of the building to the other on the side facing Mandela Street, you
could create an additional way over that edge of the building containing 2
nodes, 1 at each end, the one at the lowest numbered end with a housenumber
of 1, the one at the highest end with a housenumber of 21 then the way
itself having the interpolation tag set to all... What would be rendered by
osmarender then would be a 1 at one end and 21 at the other with a line,
potentially dotted or dashed, not sure, joining them... A tool to locate an
address should in theory then be able to guestimate how far along the way a
specific number is using this...

The final (best?) approach would be to tag each individual house number by
it's entrance, so if this building has 7 entrances with 3 flats per entrance
you could add a node for each entrance to the building, tagging the first
entrance as 1-3, the second as 4-6 etc...

This should all be fine for places that have street addresses, but, I'm
struggling with tower blocks or other buildings that are part of private
estates at the moment which I've posted on the wiki about here...
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/House_numbers/Karlsruhe_Schema#Apartment_Blocks.2C_Blocks_of_Flats.2C_Communities.2C_Business_Parks.2C_Campuses_etc...

Anyway... hope that helps...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] My slippy map

2008/12/10 Matthias Julius [EMAIL PROTECTED]

 D Tucny [EMAIL PROTECTED] writes:

  2008/12/9 Bernhard Zwischenbrugger [EMAIL PROTECTED]
 
 
   am I right in thinking that you're not restricting  it so that you can
  only view at specific zoom factors but you can also  drag the tiles
 when
  they're part-way between zooms?
 
 
  That's the big problem.
  Google Maps always snaps to a good zoom lavel - but I don't like it
 very
  much.
  I'm searching for a solution - but have no idea how to solve that.
  The user expects an excellent picture for all zoom levels, but that's
 not
  possible with raster images.
 
 
  If between zoom levels, would it give better results if you were to take
 the
  next zoom level in rather than the next zoom level out?
 
  i.e. use zoom 13 tiles shrunk slightly if at an effective zoom 12.5
 rather
  than zoom 12 tiles stretched slightly...
 
  I guess the downside would be the extra tiles that would need to be
  fetched...

 And the size of captions.  Small captions might become unreadable when
 you shrink the tiles too much.


Good point... For non-latin next right now the captions are probably a bit
too small already...

d
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Updated view of 'A year of edits on OSM' and also Santa's Routes!