headers
nick | 1 Feb 2006 01:02

Re: Returning the whole data instead of the id.

On Tuesday 31 January 2006 22:37, Immanuel Scholz wrote:
> Hi list,
>
> is anyone of the client coders using the feature, that any PUT is returning
> the newly created id of the thing just putted?

Yes, in osmeditor when I upload a group of new nodes, I allocate the IDs 
returned to each node. 

Nick
Permalink | Reply | 2 comments |
headers
Tom Carden | 1 Feb 2006 01:13
Picon

Re: Returning the whole data instead of the id.

nick <at> hogweed.org wrote:
> Yes, in osmeditor when I upload a group of new nodes, I allocate the IDs 
> returned to each node. 
>
>   

This reminds me - you kept mentioning that there seemed to be a limit to 
the number of nodes/segments you could upload in one go.

Did the change to libxml fix that by any chance?

If not, is there a ticket for it?

Tom.
Permalink | Reply | 1 comment |
headers
Frank Mohr | 1 Feb 2006 01:43
Picon
Favicon

Re: Re: OSM Schema Design

M Josenhans wrote:
>>>>> country borders,
>>>>
>>>> Although I disbelieve this should be in an streetmap database, if you
>>>> want
>>>> to enter it, make it a property on a street surrounding the country.
>>>
>>> Looks rather like a huge type of area me.
>>
>>
>> right ... but also with holes in it
> 
> 
> An area with a hole inside, I'd call such a thing a 'border'. May it be
> a border of a city, of a country, of a car production plant or just the
> border of Disneyland.

i was thinking of enclaves/exclaves

Disneyland/Paris would still be in the area of France,
but the Vatican is a hole in the area of Italy

frank

	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
(Continue reading)

Permalink | Reply | 0 comments |
headers
Immanuel Scholz | 1 Feb 2006 09:53
Picon
Picon

Re: Returning the whole data instead of the id.

Hi,

>> To update the intern data representation. If uploading a new node, the
>> offline
>> client has to GET this note after every PUT to update its data. With my
>> suggestion, this GET is implicit ;)
>
> Still, you have to do a GET before you do the PUT to be able to merge
> the tags.  So the internal representation should be pretty updated.

Huh?

There are two cases you want to do a PUT:
- uploading new nodes.
- updating existing nodes.

For the first case, you cannot do a prior GET, since it does not exist in
the database, right?

And for the second, you do not need to catch the ID in answer, since you
already know it or else you could not update the node, right? (And I think
the server does not return anything on updates anyway...)

>> > And shouldn't the rounding effect be very small?
>> Hopeful.. yes. But that's not the point, isn't it? A difference is a
>> difference.
> Well if the difference doesn't matter then you do not need to know
> about it.  But, OK, I can see a minor advantage to getting the rounded
> values.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tommy Persson | 1 Feb 2006 10:35
Picon
Picon
Picon
Favicon

Re: Returning the whole data instead of the id.


> From: "Immanuel Scholz" <immanuel.scholz <at> gmx.de>
> 
> And for the second, you do not need to catch the ID in answer, since you
> already know it or else you could not update the node, right? (And I think
> the server does not return anything on updates anyway...)

I meant that if you would like to change the coordinates for a node
you have to get the information in the node before you save the new
information since it is not possible to change just some properties
with the current API.

> 
> It does matter if you compare the values you stored in your client to the
> values in the server to detect changes that might be made by the user.
> 

How will you handle this?  If the difference is large then interupt
the update?  Or only interupt if the difference is small because if it
is large you will want to override?

/Tommy
Permalink | Reply | 0 comments |
headers
Nick Whitelegg | 1 Feb 2006 13:45
Picon
Favicon

Re: Returning the whole data instead of the id.


>This reminds me - you kept mentioning that there seemed to be a limit to
>the number of nodes/segments you could upload in one go.

>Did the change to libxml fix that by any chance?

I uploaded a fair amount of new segments and nodes in one go on Monday
night, and didn't get any problems.

Nick
http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap-dev
Permalink | Reply | 0 comments |
headers
SteveC | 1 Feb 2006 16:45
Gravatar

Re: Returning the whole data instead of the id.

*  <at>  31/01/06 11:05:41 PM immanuel.scholz <at> gmx.de wrote:
> Hi,
> 
> > > This would break code that read the current id out of the answer stream
> > > (which would need to be changed to read the id attribute from the xml
> > > answer). It is cool for all offline editors, since the lat/lon may have
> > > been changed (due rounding). This could also enable the server to do some
> > > filtering or processing on all change inputs and have the clients to
> > > update their view of the data without the need of an additional
> > > GET-request.
> >
> > Breaks the applet.
> 
> Damn, thought it would be.
> 
> Would you change the applet? I could try (but never hacked within the applet 
> before).

Yeah as time permits.

> Does speak anything against this?
> 
> > JOSM and the applet should use the same parser anbyay.
> 
> Hm... JOSM uses Java 1.5. And JOSM uses JDOM. And finally, JOSM has a 
> different internal data structure. So I don't see many common things to 
> reuse.

But that doesn't mean it *should* be like that. Maintaining multiple
Java parsers seems silly.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Preben Mikael Bohn | 1 Feb 2006 16:53
Picon

Adding street data

I've got hold of ~50 MB of data from the danish mapping agency (under a
free distribution license) which relates each address in Denmark with a
WGS84 position. No roads and other attrbutes (one-way streets, major
roads, etc) are present, however using GPS logs and this data in
combination should make it possible to map quite a few roads in Denmark.

Is Openstreemap capable of using such data (probably not?) and if not,
what would it take to implement this (I am a developer, but I have no
knowledge of openstreetmap)?

Another question: Is it possible to add properties to roads in the editor?

Best regards Preben
Permalink | Reply | 7 comments |
headers
Erik Johansson | 1 Feb 2006 17:21
Picon

Re: Adding street data

Hej Preben

On 2/1/06, Preben Mikael Bohn <preben <at> chin.dk> wrote:
> I've got hold of ~50 MB of data from the danish mapping agency (under a
> free distribution license) which relates each address in Denmark with a
> WGS84 position.

Great can you make it available?

> Is Openstreemap capable of using such data (probably not?) and if not,
> what would it take to implement this (I am a developer, but I have no
> knowledge of openstreetmap)?

The only way OSM handles metadata is through tags on nodes or
segments, right now that is used to set the name of the street. You
could use this to place your data on the OSM map, for later use.
Highly inefficient but it works now-

Just create a OSM node for each entry in your database
http PUT this into the database.

<osm version='0.2'>
<node lon='-0.148588713362387'
tags='name=Långgatan;streetnumber=12;postcode=12345'
lat='51.5278975364617'/>
</osm>

> Another question: Is it possible to add properties to roads in the editor?
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Thomas Walraet | 1 Feb 2006 17:39

Re: Adding street data

Preben Mikael Bohn a écrit :
> I've got hold of ~50 MB of data from the danish mapping agency (under a
> free distribution license) which relates each address in Denmark with a
> WGS84 position.

Is the license allow derivative works, or only redistribution for free ?

I think you should post the license on this mailing-list prior to spend 
time on any technical work to use those data.
Permalink | Reply | 1 comment |

Gmane