[OSM-dev] Priority signes
Are there any tags to map priorities on the OSM roads? P.S. Priority signs are http://en.wikipedia.org/wiki/Priority_to_the_right -- Best regards, Popov Anton. Senior Software Engineer, Cogniance Inc. Mobile: +380 68 358 52 13 Skype: popov.work Google account: Popov.UA.work MSN: popov...@hotmail.com ICQ: 461751798 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Ways containing same nodes
Thanks for you reply. I've asked about the creation possibility, because there were 2 ways and after some changeset has been commited, one way become overlapped by other. Ok, I will merge these ways using JOSM. On Wed, Jan 20, 2010 at 9:07 PM, Matthias Julius li...@julius-net.netwrote: Anton Popov apo...@cloudmade.com writes: Hello everybody, I've found two ways in Germany, that has same nodes: http://www.openstreetmap.org/browse/way/23735657 http://www.openstreetmap.org/browse/way/23735661 I've examined the history it seems that following changeset caused a problem: http://www.openstreetmap.org/browse/changeset/259367 The main questions are How this could happen? and How to correct these ways? There are many possibilities: A bug in the uploading software, the user somehow duplicating the way, the user not saving his data after uploading, or - most likely - an aborted HTTP connection after the server received the data (either by the user hitting cancel or by a broken network connection). The latter prevents the client from learning the IDs the server has assigned to new objects and on next upload it will re-upload the same objects again as new. As far as I can see correct way is 23735661 - the only missing tag is maxspeed - am I right? If the ways really have the same nodes one can do Combine Ways (C) in JOSM and JOSM will merge all tags onto one way. If they don't exactly overlap one can in JOSM select them both and all tags of both ways will be listed in the properties list with the tags that have different values displaying different. Then one can edit those tags and the values that are actually used by one of the selected ways are shown in bold in the value drop-down. Once all tag values are merged one can delete one way. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Best regards, Popov Anton. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Ways containing same nodes
Hello everybody, I've found two ways in Germany, that has same nodes: http://www.openstreetmap.org/browse/way/23735657 http://www.openstreetmap.org/browse/way/23735661 I've examined the history it seems that following changeset caused a problem: http://www.openstreetmap.org/browse/changeset/259367 The main questions are How this could happen? and How to correct these ways? As far as I can see correct way is 23735661 - the only missing tag is maxspeed - am I right? -- Best regards, Popov Anton. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [osmosis-dev] TagTransform plugin updated
Hello Dave,
I've created the only abstract class with the logic of tag transforming
already committed, after running some tests.
Best regards,
Popov Anton
On Mon, Dec 7, 2009 at 8:10 PM, Dave Stubbs osm.l...@randomjunk.co.ukwrote:
Hi,
Good to see someone working on improvements!
I just took a look at your commit.
One question: is it intentional to drop delete changes? I think that's
the current action, though not entirely sure without testing (for
which I don't have time atm).
Also it seems that most of the process is a direct cut'n'paste from
the TransformTask code. I don't think duplicating the logic in this
way is a good idea -- do you think you could refactor it to have the
core process logic separate from either task?
ie: so that TransformChangeTask becomes more like:
@Override
public void process(ChangeContainer changeContainer) {
if ( !ChangeAction.Delete.equals(changeContainer.getAction()) ) {
EntityContainer entity = changeContainer.getEntityContainer();
EntityContainer output = transformTask.process(entity);
if ( output != null )
sink.process(new ChangeContainer(output,
changeContainer.getAction());
}
}
Thanks,
Dave
On Mon, Dec 7, 2009 at 11:33 AM, Alexander Chmyr ach...@cloudmade.com
wrote:
Hello,
We have successfully updated TagTransform plugin and added new task:
--tag-transform-change (--ttc).
It works exactly as --tt task, but get as input change files (osc) and do
transformation when adding or modifying. No changes when delete action.
Kudos to Anton Popov (apo...@cogniance.com)
Alexander Chmyr
Software Engineer
Cogniance, Inc
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] TagTransform plugin updated
Hello Dave, I've understood the case and will fix that. I assume to make changes in a day or two. On Tue, Dec 8, 2009 at 12:45 PM, Dave Stubbs osm.l...@randomjunk.co.ukwrote: On Tue, Dec 8, 2009 at 10:16 AM, Anton Popov apo...@cogniance.com wrote: Hello Dave, We can split the logic for sure. I will refactor these two tasks. Speaking about delete actions, I can say I've ignored them expressly, because there is no big sense to transform(!) tags in entity, that will be deleted. I'm new to Osmosis and if you will place arguments when my assumption can be wrong I can make changes for the code. Yeah, they don't need transforming, that's fine. The issue is whether they are being dropped from the ongoing change stream? The change stream comes into the task via the process method, and the ongoing stream leaves it via the call to the Sink.process method. So creates and modifies will pass through the transform and only get piped to the sink if the transform didn't drop it, but the deletes are never sent to the sink, no matter what. As I said this was just me looking at the code, I'm fairly sure it's wrong but haven't had time to test -- just put it through this use case: create a changeset that includes a delete, then using a pass through transform you should get the same changeset out the other end, including the unaltered deletes. Dave -- Best regards, Popov Anton. Senior Software Engineer, Cogniance Inc. Mobile: +380 68 358 52 13 Skype: popov.work Google account: Popov.UA.work MSN: popov...@hotmail.com ICQ: 461751798 ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
