Re: [OSM-dev] API: version number of newly created objects.

2009-04-28 Thread D Tucny
2009/4/28 Chris Browet c...@semperpax.com

 Hi,

 I see in the api doc:
 Version numbers will most of the time begin at *1* and increase by *1*every 
 time an element is changed but this behaviour is not guaranteed and
 should not be relied upon
 I understand that phrase as I cannot assume that a newly created object
 will be at version 1.

 As a creation PUT do not return the version number (AFAIK), does that mean
 that we are suppose to do a GET on the newly created object to get the
 version number?


If you do a diff upload (
http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6#Diff_upload:_POST_.2Fapi.2F0.6.2Fchangeset.2F.23id.2Fupload)
you will get the version number back in the response and if you update an
existing individual object you will get the version number in the response,
but, as you say, as documented, creating an individual object won't return
the version... I don't know for sure, but, I'd hope that the version number
starting at 1 bit is guaranteed even if the increase by 1 isn't...

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


Re: [OSM-dev] Bittorrent

2009-04-18 Thread D Tucny
2009/4/18 Simon Ward si...@bleah.co.uk

 On Fri, Apr 17, 2009 at 08:23:19AM -0700, Paul Johnson wrote:
  Stefan de Konink wrote:
   After a few upload problems, a new torrent is available.
  
   http://wiki.openstreetmap.org/wiki/Planet.osm#Bittorrent
 
  Not to nitpick, but in terms of PR, might it be better to use a tracker
  other than The Pirate Bay?

 Selfish and wrong.  It may even help TPB if more high profile projects
 used their tracker for (legal) distribution.

 In terms of PR it could also be seen how an “open” data project
 abandoned an effective method of distributing open data.  If TPB’s
 appeal fails, it sets a bad precedent for any other tracker out there.


TPB is unreachable from here, it's been blocked for a long time... As such,
it's not very effective for me, or all the other people in the world who
find it blocked for them, and there are quite a lot... This is thanks to the
negative PR that TPB already has... They've never helped themselves in this
regard... If anything, TPB has done bad PR for BitTorrent, an open protocol
and open source implementation developed for the efficient distribution of
large datasets and now in common perception, a tool to enable one to easily
obtain copyrighted materials...

BitTorrent can be an effective method of distributing open data and setting
up a tracker for a project isn't a massive job, other open projects may well
be willing to share a tracker, which reduces that overhead... The way that
BitTorrent works, you don't need to use the biggest, most popular tracker,
you just need to have all the people wanting to share the file being able to
connect to the same one/s...

So anyway, in short, I agree with Paul, both from the PR point of view and
from the point of view that hosting it on TPB make it useless to me...

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


Re: [OSM-dev] FW: using OpenStreetMap api

2009-04-15 Thread D Tucny
2009/4/15 Mohamad Ali mohamad@intellitrac.com.au

 I tried to contact 'legal-t...@openstreetmap.org' , no body reply..


It was only 10 hrs ago, be patient... :)

Can I ask you a question , because I would like to be sure that I can use
 openstreetmap  for commercial use,

 I would like to put openstreetmap   on my website and people will access my
 site every day,
 Of course I will put the credits and licenses in my JavaScript code and
 link
 to openstreetmap in my website user interface,..
 Is that enough or should I contact 'legal-talk'?


Commercial use or the data and map tiles in their unmodified forms is
allowed as long as you provide the required attribution... Anyone can use
the data, which is the entire point of having an Open streetmap :)
If you were to modify the data or tiles and then publish the results of
those modifications I believe it can get more complex, so you'd need to
check the license and perhaps discuss the issue on the legal-talk list if
you needed to do that...

If you are only looking to provide a slippy map view, and not use the data
directly, you should check this page too which is specifically about using
the tiles produced by the mapnik based tile server run by/for the project...

http://wiki.openstreetmap.org/wiki/Tile_usage_policy

The key bits that would be potentially relevant in your situation are
1) that you shouldn't bulk download tiles, i.e. don't download all the tiles
in an area to host directly on your own server
2) the point on heavy users, which might not be an issue now, but, if your
site is, or becomes, busy then you should look into either setting up your
own local tile rendering instance, or, look at commercial providers of
rendered tiles such that you are not overloading the project public tile
server...

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


Re: [OSM-dev] openstreetmap.org as target for spamming?

2009-04-09 Thread D Tucny
2009/4/9 Stefan Keller sfkel...@gmail.com

 I'm using recaptcha in my Mediawiki installation too.
 Can recommend it.

 -S.

 2009/4/9 Łukasz Jernaś deej...@srem.org

  On Thu, Apr 9, 2009 at 9:41 AM, Tom Hughes t...@compton.nu wrote:
  Tom Hughes wrote:
 
  Maye someone with Rails skills could quickly grab an existing captcha
  solution and add it to
 
 http://trac.openstreetmap.org/browser/sites/rails_port/app/controllers/user_controller.rb
 ?
 
  All the ones I have seen so far appear to be manually done so I don't
  think a Captcha will help.
 
  OK. In this case it does look like they were automated (there are at
  least 300 or so that I have killed) so a captcha might help.

 Maybe http://recaptcha.net/plugins/mediawiki/ could help?


Surely it would be more fitting to have some form of 'point to a place on a
slippy map' type test wouldn't it? :)

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


Re: [OSM-dev] JOSM: Several tags with same key

2009-04-03 Thread D Tucny
2009/4/3 Pierre-André Jacquod pjacq...@alumni.ethz.ch

 Martin Koppenhoefer wrote:
  actually I would map the building (closed way) and 2 nodes within at
  their actual position for postbox and atm, or is it a combined postbox
  and atm?
 exactly one above the other in the wall, like:
 --
 | ATM |
 |-
 | postbox |
 ---
 regards


Then shouldn't that be two nodes? with the atm one having a layer=1 tag?

Similar to having a bar above a restaurant above a bank at the same position
but on different floors...

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


Re: [OSM-dev] Tiling the Planet and Missing Nodes

2009-03-28 Thread D Tucny
2009/3/28 Stefan de Konink ste...@konink.de


   From my last run, way id 4043882 references node 365476284 that is not
  present in the dump.  This is with planet version 090325.  Grep reveals
  that 365476284 is only present in an nd tag as part of the ref=
  statement. :-(
 
  My question is: what is the right interpretation of a missing node?
  Should I simply pretend the node reference does not exist (e.g. delete
  the vertex from the way)?

 The idea with that situation is for ways:
 - Download the way; and just reupload it, then it will be solved in the
 next run (because the way download hides invisible nodes)


This only fixes the problem of ways with nodes that shouldn't be there which
I don't believe is always the case... In most cases, nodes that should be in
a way have somehow become deleted, but, not from the way itself... The
typically accepted 'fix' for these is to modify the way in Potlatch, which,
as a byproduct of it's method of rewriting all related objects, restores the
nodes to their prior undeleted state... To blindly rewrite these damaged
ways removing the problem nodes would hide the problem but could leave the
way itself inaccurate... These ways should be manually inspected to work out
what the actual problem is and to repair it, or at the very least, a lot
more logic needs to be used in any automated process...



 For relations:
 - Download the relation; remove all nodes/ways/relations that you know
 that don't exist. Reupload it; will you get a 200; job well done ;)


Again, this isn't so simple... doing this would remove some errors (deleted
objects in a relation) and introduce new ones (relations that are missing
critical components or otherwise don't make sense)...

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


Re: [OSM-dev] planet.openstreetmap.org breakage

2009-03-19 Thread D Tucny
2009/3/19 Stefan de Konink ste...@konink.de

 On Thu, 19 Mar 2009, Grant Slater wrote:

  Patched planet files will become available shortly, but they too take
  time to generate.

 Are you saying you are going to regenerate all previous planet files?
 Isn't that a bit waste of resources?


A significant use of resources, yes, but, a waste? Probably not... As
copyright data has been found, it needs to be removed from distribution, for
the API, the current version and history versions would need to be removed
then it would be clean, but for the planet files, either a) all planet and
patch files containing this data would need to be removed from distribution
or b) past planet files would need to be modified to just remove this bad
data... I personally feel that with all the cool things people have done
with historical planet data value is demonstrated in having these historical
planet files, so, where possible, it would be good to clean them, and the
patch files, up rather than remove all the affected planet and patch files
for ever...
d
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev


Re: [OSM-dev] Improvement of tile rendering

2009-03-17 Thread D Tucny
2009/3/18 Stefan de Konink ste...@konink.de

 Jon Burgess wrote:
  On Wed, 2009-03-18 at 00:48 +0100, Stefan de Konink wrote:
  Dane Springmeyer wrote:
  I should stress though that Mod_tile is the optimal solution for tile
  rendering for most OSM related purposes.
  I wonder if an Apache module is able to provide caching. I doubt it can,
  thus requires more bandwidth right?
 
  Yes it does caching. What make you think it can not?

 I am talking about client side caching. So a client says... hey I have
 an expire thingie or i have an e-tag should I refetch it?


Here are the headers for a request and response for a single tile...

GET /16/54640/26982.png HTTP/1.1
Host: b.tile.openstreetmap.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.7)
Gecko/2009021910 Firefox/3.0.7
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en,en-gb;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.informationfreeway.org/

HTTP/1.x 200 OK
Date: Wed, 18 Mar 2009 02:54:03 GMT
Server: Apache/2.2.4 (Ubuntu)
Etag: b3431afd380b6449ac17e631eef4536d
Content-Length: 5338
Cache-Control: max-age=8987
Expires: Wed, 18 Mar 2009 05:23:50 GMT
Keep-Alive: timeout=3, max=100
Connection: Keep-Alive
Content-Type: image/png

So, it returns an Etag header, a cache-control header giving an approx 2.5hr
max-age and an Expires header also giving the same 2.5hr age... Looks good
to me :)

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


Re: [OSM-dev] Osmosis crashing due to lack of memory

2009-02-26 Thread D Tucny
2009/2/26 Emilie Laffray emilie.laff...@gmail.com

 Hi,

 I have been trying to play with the planet file and extract
 information out of it. However, it crashed on me with an out of memory
 memory regarding heap space.
 I used the following command:
 osmosis --read-xml file=planet-090218.osm enableDateParsing=no
 --way-key-value

 keyValueList=highway.motorway,highway.motorway_link,highway.trunk,highway.trunk_link,highway.primary,highway.primary_link,highway.secondary,highway.tertiary,highway.unclassified,highway.road,highway.residential,highway.living_street,highway.service,highway.track,highway.pedestrian,highway.bus_guideway,highway.path,highway.cycleway,highway.footway,highway.bridleway,highway.byway,highway.steps,highway.toll_booth,highway.ford,cycleway.lane,cycleway.track,cycleway.opposite_lane,opposite_track,cycleway.opposite,tracktype.grade1,tracktype.grade2,tracktype.grade3,tracktype.grade4,tracktype.grade5,waterway.stream,waterway.river,waterway.riverbank,waterway.canal,waterway.dock,waterway.weir,waterway.dam
 --used-node --migrate --write-xml-0.6
 file=E:\world\dump\roads\roads.osm

 I would love to avoid as much as possible to break the planet into
 bounding boxes, for the sake of simplicity initially. Maybe it is
 unrealistic but I would like to keep it that way.


In osmosis.bat is the following line...
REM # JAVACMD_OPTIONS - The options to append to the java command, typically
used to modify jvm settings such as max memory.

so, either modify osmosis.bat or, create a new file called osmosis.bat in
the all users profile directory or your profile directory, to include a 'set
JAVACMD_OPTIONS = -Xmx1024M' line (to set maximum memory usage to 1GB, if
you have enough RAM)...



 I am using the planet file uncompressed with osmosis 0.30.
 Is there something I can do? Spending hours and then seeing your task
 crashing is pretty disheartening.
 Also, is there a way to use multicore efficiently? I have looked at
 the pages but I didn't see any convincing number. I was thinking of
 maybe of getting the file to be read in one drive and writing to the
 other one, therefore avoiding the IO hit of reading and writing at the
 same time on the same drive.


Using a gzipped planet input and gzipped output may be quicker if your
facing an IO bottleneck... the compression and decompression will use more
CPU, but, significantly reduce the IO...

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


[OSM-dev] Mapnik layer fontset fonts

2009-02-19 Thread D Tucny
Hi Folks,

Does anyone have a list of fonts (or other font config info) used on the
tile server to produce the mapnik layer?

I ask as I'm working on getting a multilayer/multilanguage (Asia centric)
slippy map set up and I'm seeing characters disappearing at certain font
sizes that render fine on the normal mapnik layer...

The fontset I'm using contains the following as I'm concentrating on CJK at
the moment...
  Font face_name=DejaVu Sans Book /
  Font face_name=AR PL ShanHeiSun Uni Regular /
  Font face_name=AR PL ZenKai Uni Medium /
  Font face_name=Sazanami Mincho Regular /
  Font face_name=Sazanami Gothic Regular /
  Font face_name=Baekmuk Dotum Regular /
  Font face_name=unifont Medium /

If you want to have a look, the map is at
http://osm.newportcoastsoftware.com the language layers can be selected in
the normal way by clicking the plus at the right...

The world has been rendered without captions to zoom level 5, and all
caption layers have been also rendered to zoom level 5...
Asia has been rendered without captions to zoom level 12, caption layers are
still rendering, but currently default (name) and english (name:en) layers
are available to at least zoom level 10...

The layers available are:
Base - Default, no captions base layer
name captions - Captions using the 'name' tag for default names
name:en captions - Captions using the 'name:en' tag for English names,
falling back to name
name:zh captions - Captions using the 'name:zh' tag for Chinese names,
falling back to name
name:zh_py captions - Captions using the 'name:zh_py' tag for Chinese Pinyin
(Mandarin) names, falling back to name
name:zh_pyt captions - Captions using the 'name:zh_pyt' tag for Chinese
Pinyin names with tone marks, falling back to 'name:zh_py', falling back to
name
name:ja captions - Captions using the 'name:ja' tag for Japanese names,
falling back to name
name:ja_rm captions - Captions using the 'name:ja_rm' tag for romanised
Japanese names, falling back to name

Tiles are being generated with generate_tiles.py for viewing performance
reasons, they are currently not being produced at 256 colours because of
loss of transparency, which is kind of important for this :) as such, the
tiles may be a bit big...

Mapnik is current svn version, with only one line changed to make it build
with boost 1.33 (centos 5)
Database is being synced with diffs, but, there appears to have been a
couple of diffs missed at some point
the stylesheet is the one from svn, there do seem to be some differences to
the current rendering style of the mapnik layer though, so may be a little
out of date...
index.html was blatently pinched from www.informationfreeway.org
tile.openstreetmap.nl/README.txt instructions were useful in getting the
database set up and the data into the database
regionalised rendering details on the wiki provided the idea of using views

Thanks,

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


[OSM-dev] Mapnik layer has become confused by layers?

2009-02-12 Thread D Tucny
Hi folks,

Not sure when this started, but, mapnik seems to be getting layers wrong
when drawing objects...

e.g.
http://www.openstreetmap.org/?lat=30.297629lon=120.155582zoom=18layers=B000FTF

In this view there is a two dual carriageway primary roads that meet at a
junction at ground level (no layer tag), above the junction running north
south is a dual carriageway trunk elevated road/viaduct (layer=2), above the
primary roads, with some below the trunk and some above is a junction
consisting of a number of trunk_link roads (various layer tags) linking the
east west primary road to the trunk road... Mapnik appears to be currently
drawing all trunk_link roads below everything else, even though they are
tagged with layer tags of 1, 2 and 3 depending on which other ways they pass
over, though it's difficult to see if it's drawing them under the trunk as
there are no borders visible making it all appear to be at the same layer...


Similar confusion is also visible in other places where the same road
crosses other roads and there are link roads present...
e.g.
http://www.openstreetmap.org/?lat=30.27611lon=120.16596zoom=17layers=B000FTF-
east west primary linked to north south trunk (bicycle flyover and
roundabout between the two)
e.g.
http://www.openstreetmap.org/?lat=30.21797lon=120.171zoom=17layers=B000FTF-
No link roads present here, but, double decker bridge with primary
road at
layer 1 and trunk at layer 2 rendered with the primary road above the
trunk...
e.g.
http://www.openstreetmap.org/?lat=30.27895lon=120.19501zoom=17layers=B000FTFT-
Primary links roads at layer 1 overlaid by unclassified roads with no
layer tag

osmarender seems to get it right, even if it does look a bit messy where the
different layers join...

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


Re: [OSM-dev] Mapnik layer has become confused by layers?

2009-02-12 Thread D Tucny
2009/2/13 D Tucny d...@tucny.com

 Hi folks,

 Not sure when this started, but, mapnik seems to be getting layers wrong
 when drawing objects...

 e.g.

 http://www.openstreetmap.org/?lat=30.297629lon=120.155582zoom=18layers=B000FTF

 In this view there is a two dual carriageway primary roads that meet at a
 junction at ground level (no layer tag), above the junction running north
 south is a dual carriageway trunk elevated road/viaduct (layer=2), above the
 primary roads, with some below the trunk and some above is a junction
 consisting of a number of trunk_link roads (various layer tags) linking the
 east west primary road to the trunk road... Mapnik appears to be currently
 drawing all trunk_link roads below everything else, even though they are
 tagged with layer tags of 1, 2 and 3 depending on which other ways they pass
 over, though it's difficult to see if it's drawing them under the trunk as
 there are no borders visible making it all appear to be at the same layer...


 Similar confusion is also visible in other places where the same road
 crosses other roads and there are link roads present...
 e.g.
 http://www.openstreetmap.org/?lat=30.27611lon=120.16596zoom=17layers=B000FTF-
  east west primary linked to north south trunk (bicycle flyover and
 roundabout between the two)
 e.g.
 http://www.openstreetmap.org/?lat=30.21797lon=120.171zoom=17layers=B000FTF-
  No link roads present here, but, double decker bridge with primary road at
 layer 1 and trunk at layer 2 rendered with the primary road above the
 trunk...
 e.g.
 http://www.openstreetmap.org/?lat=30.27895lon=120.19501zoom=17layers=B000FTFT-
  Primary links roads at layer 1 overlaid by unclassified roads with no
 layer tag

 osmarender seems to get it right, even if it does look a bit messy where
 the different layers join...


The cloudmade minutely mapnik also get's this right...

e.g.
http://matt.sandbox.cloudmade.com/?lat=30.29722lon=120.15529zoom=18layers=B0

And a different area with layer issues that's not a road...

http://www.openstreetmap.org/?lat=30.266499lon=120.129264zoom=18layers=B000FTTT
http://matt.sandbox.cloudmade.com/?lat=30.266499lon=120.129264zoom=18layers=B000FTTT
Showing a building with parking on much of the top, the parking area has
holes using a multipolygon relation where parts of the building are taller
than the parking level...

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


[josm-dev] Autocompletion of numbers and access to presets

2009-02-12 Thread D Tucny
Hi folks,

I've been adding house/building/street numbers quite a bit recently, and
something that's been frustrating me a bit has been autocompletion... For
some things, such as keys and fixed values, autocompletion is nice, but
especially for numbers, it can be a pain... My work flow is this, add node,
click add property, type ad, autocompletes to addr:housenumber, tab to value
box, type number, hit enter... Quite quick to do, and with house numbers
there's a lot of them, so, speed is good... but... a problem I had at the
start of entering house numbers, and one that's still cropping up at times
is that the number gets auto completed... the result is that when I'm adding
numbers, such as 11, 13, 15, I end up with 11, 132 and 154 due to the fact
that 132 and 154 exist on another street somewhere... It's getting to be
less of a problem as there are more numbers in the area, i.e. once 13 and 15
are in, it won't try to autocomplete subsequent 13s and 15s to longer
numbers, but, it's still catching me out at times, especially if I've
grabbed a different area...

Using the address preset may help, but, as it stands, presets are not easily
accessible, or, perhaps they are only easily accessible and not quickly
accessible... I can put a shortcut on the toolbar which would help, but, I
can't seem to apply a keyboard shortcut, if I want to access the address
preset using only the keyboard, alt-p opens the present menu, but then I
have to press the up arrow 10 times, the right arrow once then the up arrow
twice... Not exactly quick...

So... a couple of things that could help as far as I see...

1) The ability to restrict autocompletion to tags only or tags and a list of
tags where the value can be autocompleted, or inversely, where the value
shouldn't be autocompleted... Not sure how simple that would be to
implement... Then autocompletion of addr:housenumber could be disabled...

2) The ability to access items off the presets menu by key strokes, i.e.
Alt-P brings up the presets menu as now, 'b' opens the Building submenu, 'a'
opens the Addresses preset window... Then Alt-P, b, a would get me to where
I needed to be quicker than using the mouse...

3) The ability to assign keyboard shortcuts to preset items, right now it
doesn't look like they can be assigned shortcuts in the shortcuts prefs, it
could be useful if they could be as the keyboard access to a specific preset
could be shortened beyond what's proposed in 2 if you need access to a
certain preset often...

I'm not sure if any of these options exist as it stands, there doesn't seem
to be a way to configure them in the preferences screen if they do... and
I'm afraid I'm not sure how hard it would be to implement them... But,
potentially some things that could be considered if someone is those bits of
the code...

Thanks,

d
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [OSM-dev] api0.6 - only one value per key?

2009-01-27 Thread D Tucny
2009/1/28 marcus.wolsc...@googlemail.com

 On Wed, 28 Jan 2009 00:07:20 +, Simon Ward si...@bleah.co.uk wrote:
  [Moved to dev; followups to dev]
 
  On Tue, Jan 27, 2009 at 10:58:25PM +, Ævar Arnfjörð Bjarmason
 wrote:
   I think multiple keys with the same name should be allowed for a
   node/way/relation.  AFAIK it's only the editors that don't currently
   let
   you do this.
 
  Yes, the API and data format supports it, but only for another 2
  months or so until we switch to 0.6 where it won't be allowed.

 I cannot find any such restriction in
 http://wiki.openstreetmap.org/wiki/0.6 .

 Could someone please clarify this?
 I implemented no changes to attribute-handling
 for the 0.6-support in my software and need
 to know if I have to explicitely disallow this
 to happen, write test-cases,... .


It's in there, under Related Database Improvements...

   - It is planned to create an unique index on the combination of object id
   and tag key, so that it will no longer be possible to have multiple
   identically named tags on the same object. This was possible until now but
   rarely used. The impact of this is being analysed.
   - The relations tables will receive an additional sequence_number
   column used for sorting the elements. Having the same member in the same
   relation twice will be allowed. The sequence_number column will not be
   exposed anywhere, it will just be used to store the sequence in which
   relation members where uploaded and to return them in the same sequence.

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


Re: [OSM-dev] api0.6 - only one value per key?

2009-01-27 Thread D Tucny
2009/1/28 D Tucny d...@tucny.com

 2009/1/28 marcus.wolsc...@googlemail.com

 On Wed, 28 Jan 2009 00:07:20 +, Simon Ward si...@bleah.co.uk wrote:
  [Moved to dev; followups to dev]
 
  On Tue, Jan 27, 2009 at 10:58:25PM +, Ævar Arnfjörð Bjarmason
 wrote:
   I think multiple keys with the same name should be allowed for a
   node/way/relation.  AFAIK it's only the editors that don't currently
   let
   you do this.
 
  Yes, the API and data format supports it, but only for another 2
  months or so until we switch to 0.6 where it won't be allowed.

 I cannot find any such restriction in
 http://wiki.openstreetmap.org/wiki/0.6 .

 Could someone please clarify this?
 I implemented no changes to attribute-handling
 for the 0.6-support in my software and need
 to know if I have to explicitely disallow this
 to happen, write test-cases,... .


 It's in there, under Related Database Improvements...

- It is planned to create an unique index on the combination of object
id and tag key, so that it will no longer be possible to have multiple
identically named tags on the same object. This was possible until now but
rarely used. The impact of this is being analysed.
- The relations tables will receive an additional sequence_number
column used for sorting the elements. Having the same member in the same
relation twice will be allowed. The sequence_number column will not be
exposed anywhere, it will just be used to store the sequence in which
relation members where uploaded and to return them in the same sequence.


And to reply to myself after noticing the subject... It's not one value per
key as such that's being mentioned here, but, only single unique keys...
i.e. you can't have multiple tags with the same key... An attempt to write
for example, two name tags on an object in 0.6 should result in an error
response from the API...

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


Re: [OSM-dev] 'Up-to-Date', serving ondemand live Mapnik data

2009-01-19 Thread D Tucny
2009/1/19 Christopher Schmidt crschm...@metacarta.com

 Hey,

 Using the osm2pgsql diff loading code, and osmosis's --rci, I've got an
 up to date copy of the Mapnik database being maintained on a server I
 have access to. I put together a little bookmarklet that lets you do a
 'live view' of any area by pressing a button.

  http://labs.metacarta.com/osm/up-to-date/

 Since this is not tiled at all, the performance is not likely to be great,
 but it does make an interesting demo.

 As usual, the data is working from osmosis minutely diffs, so it will be
 delayed in the same way those are.

 For the record, loading daily diffs took about one hour apiece (after
 spending the 10.5 hours to get a planet loaded). (Range was from 45m to
 70m; the latter was during a vaccum run, I believe.)

 All in all, a pretty simple task; just load a planet, load diffs with -a
 -- I did this manually to get caught up to the latest hour -- then turn
 on --rci.

 Feedback welcome,


One quick note... It looks like UTF8 data has been broken at some point...
example of area that this is visible below...

http://www.informationfreeway.org/?lat=30.287874917085606lon=120.12903655645077zoom=16layers=F0F0B0F


Apart from that little problem it looks pretty cool... Of course, if the
mapnik layer was getting minutely diffs applied along with automatic marking
of tiles with changes as dirty, that would be even cooler :)

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


Re: [OSM-dev] 'Up-to-Date', serving ondemand live Mapnik data

2009-01-19 Thread D Tucny
2009/1/19 Frederik Ramm frede...@remote.org

 Hi,

 D Tucny wrote:

 One quick note... It looks like UTF8 data has been broken at some point...


 I guess that's what is meant by potential gotchas at the bottom of the
 Minutely Mapnik page:

 When creating your database, make sure you specify the encoding as utf-8,
 otherwise you will get crappy encoding issues. (This is currently the case
 for the Up-to-Date DB: I'll probably wait until the new planet is out, and
 update it after it comes out.)


Ahh, hadn't read that page yet, thanks Frederik...

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


Re: [josm-dev] JOSM Fail

2009-01-16 Thread D Tucny
2009/1/17 Rolf Bode-Meyer rob...@gmail.com

 2009/1/16 Sascha Silbe sascha-ml-gis-osm-josm-...@silbe.org:
  On Fri, Jan 16, 2009 at 02:21:27PM +0100, Pieren wrote:
 
  Where is the limit of making harder commands for _intentional_ actions
  just to prevent _unintentional_ actions ? It is very hard to find the
  right balance between newcomers and experimented users.
 
  This isn't about newcomers vs. experienced users. I _am_ experienced and
  during my normal work I _often_ move objects when I want to select
 something
  instead, just because JOSM binds two separate actions to the same input.

 Huh? What two separate actions? The same action (moving) _should_ need
 the same input (click and drag) regardless what is to be moved.


I guess it's the select box and drag move being both the same that's
referred to here...



  If there's a config option I have to set to prevent it from happening:
 Fine
  for me. I need special configs for most programs anyway, this won't make
 a
  difference.

 Having said above in my work with JOSM accidentally dragging a way
 almost only happens when I want to add a new node by clicking a
 virtual node.
 Right now CTRL *prevents* creating a new node when clicking on a
 virtual node. So from this experience I would see reversal of
 CTRL+click on a way as improvement.


I preferred the old modeful JOSM, but, short of splitting out the modes
again, perhaps some tweaking of the sensitivity to nearby objects would make
it more difficult to select features you don't want to and easier to select
them you do, as long as you are reasonably accurate with your clicking...

d
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [OSM-dev] Potlatch - really BAD bug

2009-01-12 Thread D Tucny
2009/1/13 Eddy Petrișor eddy.petri...@gmail.com

 Hello,

 We have just seen that a portion of the map I edited yesterday with
 Potlatch is now really broken, is missing lots of points and has its
 history broken.


 http://openstreetmap.org/?lat=44.86196lon=24.89171zoom=16layers=B000FTTT

 This is easily visible when comparing mapnik and osmarender views and
 confronting them with the data.


 What's even more weirder is the fact that if I try to edit with
 Potlatch, the way is displayed correctly, as if stale data was read of
 as if Mapnik's data was read.

 I tried to use JOSM and I saw that the broken data is shown (the
 straight line, not the old good data).


 I also tried changing the browser and the bug is reproducible (on
 Firefox and on Epiphany; platform is Debian GNU/Linux amd64 (x86_64) ).



 Please help, this is the worst bug I've seen in Potlatch and it has a
 huge impact on its usability and reliability. At the same time, I am
 starting to get worried about the correctness of the data I am seeing
 and I am worried about Potlatch trashing the data is touching.


There was a post 12 hours ago to the talk list about the exact same thing...

Richard the author of potlatch explained the issue in his reply to that post
11 hours ago as being a partial written save due to server load or network
problems or some other weird issue, the result being that ways can contain
nodes that are deleted...

As Richard described in his mail, the best tool to fix this is potlatch
itself, reopen the area in Potlatch, modify the way that has a problem, e.g.
by moving a node then moving it back, then unselect it and the data will be
resaved with any missing nodes reinstated...

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


Re: [OSM-dev] database history

2009-01-05 Thread D Tucny
2009/1/6 Martin Koppenhoefer dieterdre...@gmail.com

 I was looking on the history of this way:

 http://www.openstreetmap.org/api/0.5/way/23322317/history

 and found, that the first 3 are completely the same (beside that the first
 entry and No. 2 and 3 have a different created by-tag), or am I missing
 something? Is this a case that can be found more often?


If you have a look at the nodes in the way, some of them changed position...
If I recall correctly, potlatch, the online editor save a new version of the
way, and potentially all nodes within it, if any part of the way is
modified... In this case, only changes to node positions occurred between
the second and third versions being saved...
Specifically, this node
http://www.openstreetmap.org/api/0.5/node/252528351/history

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


Re: [OSM-dev] ROMA servers down - osmosis large way problem

2008-12-31 Thread D Tucny
2008/12/31 Stefan de Konink ste...@konink.de

 D Tucny wrote:

 I'm not seeing it...


 Let me first enlight you with the non-variated idea.

 You seem to miss the point that to see the rest of the way:

1) a request can be made with a new bbox like now is common practice
if you want to edit a larger area


 But how do you know where the rest of the way is?



 Ascii art:

 Your viewport/bbox;

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

 Nodes in the way;
  ---
 |   |
 |   |
 |.. |
 | .  .  |
 |   .   |
  ---

 Explicit order of them;

  ---
 |   |
 |26 |
 |.   3. |
 | .  .  4   |
 | 1 .   |
  ---

 How the editor draws it:
  ---
 |   |
 |   |
 |.,   o |
 | o,'  ',.  |
 | ',o   |
  ---
 *see below for revisted thing*


 User thinks; mmm... that way is outside my bbox, lets request the area next
 to it. Now that area will also return a partial way;

  ---
 |---|--
 |   |   |  |
 |.  | . |  |
 | .  .  |   |  |
 |   |   |  |
  ---|---   |
|  |
 --

 The editor merges the result;

  ---
 |   |--
 |  |
 |...   .   |
 | .  . |
 |   .   .  |
  ---|  |
|. |
 --


 And now it can connect; 1, 2, 3, 4, 5, 6, 7, 8, 9

  ---,
 |   +--
 |  |
 |   ,.,.-.--.  |
 | .'   '.,. ,  |
 |  '.   .  |
  ---+, ,   |
|.,|
 --


Attempting to use ASCII art to illustrate my example... OK, as an
example... I get a bbox that covers a 500m x 500m area... 10 ways run
through that area, including 2 I'm actually interested in... right now, as
long as those 10 ways have nodes within the bbox I get them all and I can
see how they interact and where they go after leaving my bbox giving a
useful hint as to where to expand my bbox should I want to edit a way that
leaves it... With your suggestion I could see that I could have say 1 line,
between 2 nodes and and 5 additional standalone nodes, the only thing I know
is that the two nodes joined are part of one way and the other 5 nodes are
either not part of that way, or, if they are, that there are other nodes,
somewhere outside of the bbox that connects them... if I select the one
visible way, as none of the nodes are highlighted, I'd know that they were
not part of that way, so, they must be either standalone nodes that are not
part of a way, which, with their lack of tags would suggest that they were
bad edits, or, they are indeed part of a way, but for which there are no
other nodes to be connected to... if we assume that they were further
highlighted in your suggestion to show that they were special way nodes as
opposed to non way nodes, I'd know they were part of a way, but, I don't
know which way or where infact additional nodes are... I can blindly extend
the bbox and cross my fingers hoping I'll get more nodes to be able to
visualise part of the way, or, I guess, the editor can be made to give me a
list of ways that are missing nodes so that I can download them in full
manually...

bbox:

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

Returned data:

 ---
| . |
|  .|
|  .  . |
|  .|
| .  .  |
 ---

Order of nodes (multiple ways):

 ---
| 8 |
|  4|
|  3  4 |
|  4|
| 2  2  |
 ---

How the editor draws them...

 ---
| o |
|  o|
|  oo |
|  o|
| o  o  |
 ---

How I'd expect the editor to draw them, even with partial ways...

o
\
  \  o  o
\|  |
-|\-|--
   | |  |.  |
o--|-+--+\---.|---o
 o--+-+.--\--+o
o--|-+--+.\---|---o
   | .  . \ |
-|---|- \
 |   |o
 |   o
 o

Expanding bboxes gets some of the nodes, but, would need to be repeated in
each direction to get all of them, with no guarantees if the bbox was not
expanded far enough...





 2) CLick on the way and do a full

  So replacing one request with multiple requests... erm... Assuming you
 could actually find the way...


 If a part of your way is visible you should be able to request it by the
 usual 'rest' command. /ways/[id] or alternatively multible bboxes

Re: [OSM-dev] ROMA servers down - osmosis large way problem

2008-12-28 Thread D Tucny
2008/12/29 Jeremy Adams mile...@king-nerd.com

 Hey all,

 There's an issue with the minute change file
 200812290912-200812290913.osc.gz.
 It contains a way which has over 40k nodes.  It's an administrative
 boundary
 which appears to enclose all of Quebec.  It's way id is 29309772.  When
 osmosis
 attempts to process this file it fails.  The relevant parts of the error
 appear
 to be Unable to insert new way node and a pgsql error ERROR: smallint
 out of
 range.

 I'm sure I can find the way and split it into smaller chunks, but what's
 the
 process for getting the ROMA servers running again?  Can we just remove the
 reference to the way in the changeset and continue updating?  The way
 should be
 added back in once it's split and reuploaded, correct?

 -Jeremy


The same problem happened on 31st October...

Subject: HEADS UP osmosis pgsql schema users Was: psql osmosis simple shema
/ smallint out of range

On Fri, Oct 31, 2008 at 11:17:16AM +0100, Florian Lohoff wrote:
 Hi,
 i just discovered that osmosis was not able to apply the hourly osc file
 starting 2008-10-29T20:00:00Z - It failed with:

 2008-10-31 11:09:52 CET ERROR:  smallint out of range
 2008-10-31 11:09:52 CET STATEMENT:  INSERT INTO way_nodes (way_id,
node_id, sequence_id) VALUES ($1, $2, $3)

 Is there a way with 2^16 aka 65536 nodes?

 Or did someone manage to enter a completely broken sequence number?
... [show rest of
quotehttp://www.nabble.com/psql-osmosis-simple-shemasmallint-out-of-range-td20263104.html#
]
... [rest of quote removed]
Its 2^15 because it signed - and yes - somebody managed to get abovE:

osm= select max(sequence_id) from way_nodes;
  max
  ---
   39767
  (1 row)

osm= select * from way_nodes where sequence_id = 39767;
  way_id  |  node_id  | sequence_id
  --+---+-
   28098452 | 308532457 |   39767

I converted the smallint to int ...

Flo

So, perhaps following Flo's lead and changing the smallint to int would be
the best approach for dealing with getting the ROMA servers back up and
running...

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


Re: [OSM-dev] internal server error: informationfreeway.org/api/0.5/way[name=Vilhonvuorenkatu]

2008-12-22 Thread D Tucny
2008/12/23 Timo Juhani Lindfors timo.lindf...@iki.fi

 Hi,

 any idea why

 $ wget -O a '
 http://www.informationfreeway.org/api/0.5/way[name=Vilhonvuorenkatu]http://www.informationfreeway.org/api/0.5/way%5Bname=Vilhonvuorenkatu%5D
 '
 Warning: wildcards not supported in HTTP.
 --18:02:46--
 http://www.informationfreeway.org/api/0.5/way[name=Vilhonvuorenkatu]http://www.informationfreeway.org/api/0.5/way%5Bname=Vilhonvuorenkatu%5D
   = `a'
 Resolving www.informationfreeway.org... 80.68.90.42
 Connecting to www.informationfreeway.org|80.68.90.42|:80... connected.
 HTTP request sent, awaiting response... 302 Found
 Location:
 http://osmxapi.hypercube.telascience.org/api/0.5/way%5bname=Vilhonvuorenkatu%5d[following]
 --18:02:46--
 http://osmxapi.hypercube.telascience.org/api/0.5/way%5bname=Vilhonvuorenkatu%5d
   = `a'
 Resolving osmxapi.hypercube.telascience.org... 137.110.119.130
 Connecting to osmxapi.hypercube.telascience.org|137.110.119.130|:80...
 connected.
 HTTP request sent, awaiting response... 501 Internal Server Error
 18:03:13 ERROR 501: Internal Server Error.

 fails with internal server error?


Because all osmxapi requests are currently failing with an internal server
error?

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


Re: [OSM-dev] Osmarender not always showing latest data

2008-12-16 Thread D Tucny
I'm seeing the same elsewhere too...
Quite a few things are showing older versions or not showing up at all while
in the same tile features added today are present...

Way 28728177 is an example of one that is missing from the t...@h rendering at
as of now...

d

2008/12/16 Rowland Shaw rowland.s...@gmail.com

 Looks like osmarender is doing something odd again:

 http://www.openstreetmap.org/?lat=51.5443lon=0.75487zoom=16layers=0B00FTTT

 And this time a re-render from informationfreeway is not fixing it :(
 (It appears to have lost a bunch of fixes I did around 2008-11-27
 21:25:52). Bizarrely the Mapnik layer is better in this area...


 2008/12/16 Milenko mile...@king-nerd.com:
  mile...@king-nerd.com wrote:
  I haven't figured out how the server got out of sync with the main api
  yet.  My best guess is that I somehow missed part of a day or a few
 hours
  when I initially brought the server online.  If I remember correctly
 the
  timeframes are about the same.
 
  Okay, hopefully it was a once off.
  The only issue I've had with --rci was during the api outtage last
  weekend.  The main server produced a 0-byte minute diff during the
  outtage and osmosis wouldn't scan past that file.  I had to apply the
  hourly diff and then go from there.
 
  Can you let me know if this happens again?  That seems odd.  I should
  never create 0 byte diffs.  At a minimum they should be 110 bytes which
 is
  an osmChange file containing no data.  I don't update the server
 timestamp
  until a diff file is successfully generated and available.  That way
  clients should never download an invalid file.  The only exception to
 this
  is when utf-8 issues crop up in the main db and osmosis generates a
 dodgy
  file on the server that can't be processed.
 
 
  If it comes up again I'll let you know.  Like I said, it was during the
  outtage so maybe the db went down as osmosis was opening the file for
  writing or something like that.
 
  -Jeremy
 
 
 
  ___
  dev mailing list
  dev@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/dev
 

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

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


Re: [OSM-dev] bulk_import.pl

2008-12-15 Thread D Tucny
2008/12/15 Wolfgang W. Wasserburger o...@wasserburger.at

  Hi all,


 I should do some large imports for Austria; the data has allready merged
 node ids and is organzied in osm-change files; imports are also discussed
 with the local community.

 Import sizes seem to be to large to use JOSM, so we have to do
 bulk_imports. Reading some Wiki pages I could not find out how to install
 the pearl script. Trying it on Win XP or Ubuntu I had no chance to get it
 running.

 Has omeone a 5 step tip how to get it running?

 It would help me a lot.

 best regards from Vienna, Austria (no kangaroos here ;-)

 Wolfgang


Wolfgang,

How far are you getting? The script itself doesn't need much installing,
but, there are a few dependencies... If you are missing any then when you
run the script like 'perl bulk_upload.pl' it should fail with an error
message telling you what is missing...

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


Re: [OSM-dev] surveillance cams not shown in any render

2008-12-12 Thread D Tucny
2008/12/12 Eddy Petrișor eddy.petri...@gmail.com

 2008/12/11 Shaun McDonald sh...@shaunmcdonald.me.uk:
 
  On 11 Dec 2008, at 19:48, Ulf Lamping wrote:
 
  Eddy Petrișor schrieb:
 
  Solution 1: add an extra tag traffic which can be yes for such
 cameras
 
  Solution 2: new value for man_made:  man_made=traffic_surveillance
  for such cameras
 
 
  Solution 3: Use highway=speed_camera which is already used ~500 times
  and also will show up at least in JOSM.
 
  Real solution: use a custom rendering of the map data:
  http://osm.vdska.de/

 Why would I prefer to use a custom rendering instead of clarifying the
 tags, usage and quirks and push for rendering support in Mapnik and
 Osmarender?


If everything that could be tagged (well, everything can be tagged due to
the flexibility of the tagging scheme) got tagged and got rendered on a map
the map would be very feature full, but, probably useless... Mapnik can
render anything you want... The Mapnik layer on OSM doesn't render
everything, it aims to provide a generic useful view of the data...
osmarender can render anything you want, but, the osmarender layer on OSM
also doesn't render everything... With the data stored in OSM and everyone's
different requirements for maps, I think it would be awesome if there was a
way that people could easily build maps with the information and features
that they want, whether that's by multiple layers of rendered data that can
be overlaid or whether it's just finding a way of providing users with a
lower cost entry to being able to extract the information from OSM and get
it rendered, all is good... Right now, custom rendering of the map data is
still somewhat above beginner level difficulty... But... Custom output based
on OSM data would seem to be the way forward, but, it's not necessarily a
service that OSM should provide, if the generation of these renderings was
done by OSM it would consume a lot of OSMs resources, both in terms of
people's time in development as well as financial resources in building the
infrastructure to support it...

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


Re: [OSM-dev] surveillance cams not shown in any render

2008-12-12 Thread D Tucny
2008/12/12 Eddy Petrișor eddy.petri...@gmail.com

 2008/12/12 80n 80n...@gmail.com:
  On Fri, Dec 12, 2008 at 1:03 PM, Eddy Petrișor eddy.petri...@gmail.com
  wrote:
 
  2008/12/11 Shaun McDonald sh...@shaunmcdonald.me.uk:
  
   On 11 Dec 2008, at 19:48, Ulf Lamping wrote:
  
   Eddy Petrișor schrieb:
  
   Solution 1: add an extra tag traffic which can be yes for such
   cameras
  
   Solution 2: new value for man_made:  man_made=traffic_surveillance
   for such cameras
  
  
   Solution 3: Use highway=speed_camera which is already used ~500 times
   and also will show up at least in JOSM.
  
   Real solution: use a custom rendering of the map data:
   http://osm.vdska.de/
 
  Why would I prefer to use a custom rendering instead of clarifying the
  tags, usage and quirks and push for rendering support in Mapnik and
  Osmarender?
 
  Speed cameras did used to be rendered in Osmarender.  Not sure whether it
  has been removed deliberately (some people are opposed to helping
 motorists

 I am not clear how marking cameras *is* helping people break the law.
 They rather help them *not* break the law.
 At least here in Romania, such cameras are marked as present at the
 entry in the area where they are present, so the only help is to
 pinpoint the location, instead of being aware of an area.


I'm sorry, but... The speed limit doesn't only apply where cameras are
located... Marking speed cameras doesn't help people not break the law, it
would only help people avoid being caught for breaking the law...



 Personally I find myself slightly speeding (up to 5-7km/h more than
 legal) occasionaly in villages or hamlets, since the legal speed
 (50km/h) is between gears, but I am extra-careful in the surveilled
 areas in order not to get fined accidentally.


I'm sure you have many gears that cover speeds below 50km/h... The reality
of it is that you, like many drivers, prefer to drive a little faster... The
legal speed limit is 50km/h, it doesn't mean you have to drive 50km/h, it
means you must not exceed 50km/h...



 I know that technically/legally I am speeding, but technically, the
 tachometers could have errors and practically my speeding could be
 compensated by good reaction time, while somebody else, even under
 legal speed limit might not have that skill.


You are right, your speedometer could be inaccurate and while you think you
are speeding, it may be that the real speed is lower... But... It could also
be that the real speed is higher if errors are present...

I agree also that someone with good reaction times and good driving skills
could be safer at a higher speed than someone with slower reaction times
and/or poor driving skills... but... the law is the law... It doesn't make
you less guilty of speeding if you are a good driver... But, it might make
the difference between being charged with speeding and dangerous or careless
driving...



 What I am trying to say is that the the legal speed limit is an
 artificial way to keep accidents under control, but since I am careful
 even when I speeding, the goal is achieved anyway, and I think *that*
 is the important part.


Whatever anyone's feelings on what a law is supposed to be for and how that
should or should not affect them is really irrelevant when it comes to
mapping... (almost back on topic here ;)) If you want to lobby for the laws
to be changed, you a free to go chase that... but... OSM is about the
data... Recording the speed limit on a road will help people avoid breaking
the law (if they have that data available to them while driving on the
road)... Recording where safety/speed/control/enforcement/whatever else type
of cameras are could be useful to people who want to speed but don't want to
get caught... But... I don't feel it has a place on the standard map...



  break the law) or accidentally (never attribute to malice...).

 I always thought that the Mapnik render was a render for general
 usage, but slightly biased toward driving and pedestrian usage. That's
 way I thought it would be appropriate for cameras to be rendered in
 Mapnik and Osmarender.


Many features are valuable to everyone... Many features are valuable to
some... Some features appear on the map... Location of speed cameras
wouldn't in my opinion be of use to law abiding citizens... Marking of speed
limit changes would be more useful I feel...

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


Re: [OSM-dev] surveillance cams not shown in any render

2008-12-12 Thread D Tucny
2008/12/12 Eddy Petrișor eddy.petri...@gmail.com

 2008/12/12 D Tucny d...@tucny.com:
  2008/12/12 Eddy Petrișor eddy.petri...@gmail.com
 
  2008/12/11 Ulf Lamping ulf.lamp...@googlemail.com:
   Eddy Petrișor schrieb:
  
   Solution 1: add an extra tag traffic which can be yes for such
   cameras
  
   Solution 2: new value for man_made:  man_made=traffic_surveillance
   for such cameras
  
  
   Solution 3: Use highway=speed_camera which is already used ~500 times
   and
   also will show up at least in JOSM.
 
  And what happens for intersections that are both surveilled and do
  have traffic lights?
  You just add another distinct node just for that?
 
  Yes, one for the location of the CCTV camera sounds good...
 
 
  Also, I think the idea to call it *speed* camera is not that great
  since it can detect/trigger/be used for other traffic-related fines,
  such as illegal overtakes, level crossing related illegalities, etc.
 
  Are you sure? Typically there are two types of camera, those that are
 used
  for automatic recording of offenses, speed cameras, red light cameras,
  etc... and then there are CCTV cameras for surveillance and monitoring of
  traffic, typically recorded but manually operated...

 Is there a need to have 2 different values for those types? I think
 that it would be better if an extra tag would be used to make that
 distinction. In fact, as a driver you'd be more aware that you should
 be extra-careful not to accidentally break the law, no matter the
 local surveillance type.


I'd suggest that surveillance cameras or CCTV should be grouped together and
enforcement snapshot capturing cameras relating only to roads should be
grouped together... I'm sure there are plenty of privacy enthusiasts that
would love to make a map of CCTV coverage allowing them to walk in it's
shadows, so, they could go with the surveillance tag and make a map using
that, also, I'm sure there are people who'd like to break traffic laws, so
they could make a map of enforcement cameras to allow them to know where
they could be caught by an automatic law enforcement device...

I'd suggest that surveillance and enforcement are sufficiently different
that they are split...



 So I think this pair would do the trick.

 k=highway v=traffic_surveillance
 k=surveillance v=manual/speed/automatic/red_light/all


  And why, if is already used, is not documented on the Map_Features
  page? Is a discussion as this one necessary first?
 
  The Map Features page doesn't document everything that is widely used, it
  doesn't even document everything that is rendered... There are many
 proposed
  tags that are widely used but haven't made it on to Map Features, there
 are
  some tags on Map Features that are very rarely used... There are more
 tags
  that don't appear as proposed tags or on Map Features but have been used
  widely... Whether a positive or a negative thing, individuals thoughts on
 it
  vary, tags are free text, you could invent your own tag and use it as you
  saw fit for anything you wanted, but you wouldn't have to document it,
  renders wouldn't have to support it...

 Of course, but I'd rather have documented things/situations that match
 any of these:
 - are commonly used (which the current page seems to cover quite well)
 - are likely to be used in exceptional situations but aren't clearly
 documented (sometimes documented on other pages with or without links
 from the Feture page)
 - are likely to raise questions for newbies (sometimes documented
 directly on that page)


I'd love a document entitled 'How to map - A tag for every circumstance, all
in full detail with illustrations!'... But... Such a thing a) doesn't exist
and b) would be virtually impossible to put together and maintain with the
flexibility of tagging in OSM... You're welcome to try if you want to
though... ;)

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


Re: [josm-dev] Crowd sourced Testing of OSM API 0.6

2008-12-11 Thread D Tucny
2008/12/11 Shaun McDonald [EMAIL PROTECTED]

 Hi,

 As the 0.6 XML API is now feature complete, I'd like to start a push
 for getting it tested, to iron on the final bugs prior to going live.

 Can you all please take a look at the following page to find out more
 about testing the 0.6 API:

 http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6/Crowd_sourced_Testing

 And then please put your testing hats on to find the bugs.


One quick question... erm... ok, two actually now, well, one's a problem...
Uploading a changeset doesn't seem to have a real progress bar... it shows
full from the start is this supposed to work? Second issue, not sure if it's
been fixed, I'll update to the latest release when it finishes downloading,
but, while waiting for the upload to complete the following happened... I'd
guess it was a connection reset or something, but, not sure what JOSM was
doing in trying to retry...

Defaults for osm-server.version differ: 0.6 != 0.5
upload to:
http://api06.dev.openstreetmap.org/api/0.6/changeset/25/upload...conn
ected
backing off for 10 seconds...retrying (9 left)
Defaults for osm-server.version differ: 0.6 != 0.5
upload to:
http://api06.dev.openstreetmap.org/api/0.6/changeset/25/close...Defau
lts for osm-server.version differ: 0.6 != 0.5
connected
Defaults for osm-server.version differ: 0.6 != 0.5
upload to:
http://api06.dev.openstreetmap.org/api/0.6/changeset/25/close...Defau
lts for osm-server.version differ: 0.6 != 0.5
connected

Path: trunk
URL: http://josm.openstreetmap.de/svn/trunk
Repository Root: http://josm.openstreetmap.de/svn
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Revision: 1097
Node Kind: directory
Last Changed Author: framm
Last Changed Rev: 1097
Last Changed Date: 2008-12-01 02:04:27 +0100 (Mon, 01 Dec 2008)


java.lang.RuntimeException: Unexpected end of file from server
java.net.SocketException
at
org.openstreetmap.josm.io.OsmServerWriter.stopChangeset(OsmServerWriter.java:475)
at
org.openstreetmap.josm.io.OsmServerWriter.uploadOsm(OsmServerWriter.java:156)
at
org.openstreetmap.josm.actions.UploadAction$2.realRun(UploadAction.java:152)
at
org.openstreetmap.josm.gui.PleaseWaitRunnable.run(PleaseWaitRunnable.java:84)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.SocketException: Unexpected end of file from server
at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown
Source)
at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at
org.openstreetmap.josm.io.OsmServerWriter.stopChangeset(OsmServerWriter.java:416)
... 6 more
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [OSM-dev] Editing outside of bounding box

2008-12-09 Thread D Tucny
2008/12/9 Dominik Spies [EMAIL PROTECTED]

 Hi,

 It seems to be that editing data outside of a bounding box generates a
 warning in JOSM. (This is not a JOSM question!)

 At first, it seems to be obvious: delete a way with all its nodes,
 where some nodes could be part of way thats not loaded into the
 editor.
 Okay, but where exactly is the problem? The editor will try to delete
 the node, will recieve a 412 Error and recognize hey i can't delete
 that node because... and it is all fine.

 Do I miss something important?


I think the idea is the warn you beforehand rather than the first warning
being that the upload for a certain node number has failed, then having to
mess around trying to recover that node so that the rest of your upload can
continue until the next node fails... Or are you suggesting that when
uploading it should just ignore errors that could be considered to be user
error?

The API should keep the data in sync these days and with the next version
will do even more to ensure that's the case... But... Having the editor warn
you of potential problems before you start bouncing off the API does to me
seem like a good idea...

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


Re: [OSM-dev] Toll Booth - One Side of Road

2008-12-05 Thread D Tucny
2008/12/6 MilesTogoe [EMAIL PROTECTED]

 wondering what is the best way to tag a toll booth that is only on one
 side of the road (one direction) In the US we have many of these at
 bridges.


Is there separation between the two directions of traffic across the bridge?
If so, then it would be best for it to be two separate one way ways... Then
putting the toll booth just on one side wouldn't be a problem...

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


Re: [OSM-dev] Chinese font questiong! (中文 字体问题)

2008-08-11 Thread D Tucny
2008/8/11 Grant Slater [EMAIL PROTECTED]

 wit wrote:
  hi all :
see title!

 Subject: 中文字体问题
 Google Translate Subject: Chinese character issue

 Where is the problem?
 What is wrong with the Chinese characters?

 Google Translate: 哪里是问题呢?
 有什么不妥的中文字符?

 http://www.google.cn/language_tools?hl=zh-CN


Maybe it's just the randomness of font availability on renderers of the
osmarender layer. Since Mapnik has been fixed it is now looking good.
可能这个问题就是不是每个人有中文的书体在osmarender的层. Mapnik现在修好了所以现在蛮好看.

(Apologies for poor quality of Chinese)

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