Re: [OSM-dev] A PostgreSQL extension for real-time simplification of objects in OSM API database

[RTOSM DOOPAS]

The simplified result of many objects are topologically consistent,
which means any two objects share a node in original datasets will
share the same node in their simplified version. However, the topology
preservation is a complicated issue for data simplification, more
tests are needed.


On Thu, Nov 17, 2016 at 9:42 PM, Jukka Rahkonen
 wrote:
> Martin Koppenhoefer wrote 2016-11-17 14:39:
>>
>> 2016-11-17 11:08 GMT+01:00 Rory McCann :
>>
>>> But... isn't there a danger that the mapper will load this
>>> simplified/reduced object in JOSM (etc), change the tags, then press
>>> upload? And then upload the simplified/reduced geometry? Which will
>>> make
>>> the OSM data worse?
>>
>>
>> there would have to be precautions, the editors supporting reduced
>> data download would have to take care that only unreduced data can be
>> edited and uploaded. Maybe the API-server restituting different ids
>> for reduced data could help here as well, so even if the data consumer
>> / editor doesn't implement a special rule and someone tried to upload
>> simplefied data it would not overwrite the un-simplified OSM elements
>> or could be rejected.
>
>
> There can be a need to make the features which are edited to match with
> other existing features. If those other features are reduced ones the result
> may not be what was expected. It may be hard to make this system reliable.
>
> -Jukka Rahkonen-
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev

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

Re: [OSM-dev] A PostgreSQL extension for real-time simplification of objects in OSM API database

[RTOSM DOOPAS]

To make the whole cycle of data production in OpenStreetMap community
to take advantage of the extension, I think many redesigns in
server-side and client-side are needed.

and I don't think a temporary ID for simplified object is a good
practice because it brings extra work to maintain the relationship
between the IDs of un-simplified and simplified objects. A flag for
the object to indicate  whether it is been simplified is simpler.


On Thu, Nov 17, 2016 at 8:39 PM, Martin Koppenhoefer
 wrote:
>
> 2016-11-17 11:08 GMT+01:00 Rory McCann :
>>
>> But... isn't there a danger that the mapper will load this
>> simplified/reduced object in JOSM (etc), change the tags, then press
>> upload? And then upload the simplified/reduced geometry? Which will make
>> the OSM data worse?
>
>
>
> there would have to be precautions, the editors supporting reduced data
> download would have to take care that only unreduced data can be edited and
> uploaded. Maybe the API-server restituting different ids for reduced data
> could help here as well, so even if the data consumer / editor doesn't
> implement a special rule and someone tried to upload simplefied data it
> would not overwrite the un-simplified OSM elements or could be rejected.
>
> Cheers,
> Martin

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

Re: [OSM-dev] A PostgreSQL extension for real-time simplification of objects in OSM API database

[RTOSM DOOPAS]

There are many things to do before the rtosm can actually work for the
osm online data editing.

1.  At server side, editing API must change to tell the client whether
an object is simplified or not.
2.  At client side, data editor must create new rules or re-program to
use the rtosm served data.

There is no painless solution to use rtosm in current editor.

I am thinking that perhaps the most suitable use case for the rtosm is
to take peek of some huge relation or ways in browser :

https://www.openstreetmap.org/relation/id

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

Re: Github mirror not updated

[Simon Legner]

Hi all,

the mirror is up again. See
https://josm.openstreetmap.de/ticket/6887#comment:16 for details.

Feel free to reopen https://josm.openstreetmap.de/ticket/6887 whenever
there are problems with the JOSM GitHub mirror.

Simon


On Sat, Oct 29, 2016 at 12:40 AM, Simon Legner  wrote:
> Hi,
>
> I run the mirror. The script is located here:
> https://github.com/simon04/josm-mirror and see
> https://josm.openstreetmap.de/ticket/6887 for earlier problems.
>
> The cause for the current broken-ness is:
> $ git svn rebase
> Checksum mismatch: src/org/openstreetmap/josm/data/coor/EastNorth.java
> 77fca040915bef6c6fd77e43c35d952c684b9d3d
> expected: e3c9169bad42e3154887b60a20bbea8b
>  got: da2689e0e3989a6c2bc5b5449ad570eb
>
> I'll try to resolve this asap (tomorrow evening?).
>
> Simon
>
>
> On Fri, Oct 28, 2016 at 8:32 PM, Wiktor Niesiobedzki  wrote:
>> Hi,
>>
>> It looks like GitHub mirror of OSM is not updated any more. Last
>> update was on 21st of October.
>>
>> What needs to be done to bring this service up?
>>
>> Or shall I just setup my own sync service with my JOSM GitHub mirror?
>>
>>
>> Cheers,
>>
>> Wiktor
>>
>> ___
>> josm-dev mailing list
>> josm-dev@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/josm-dev

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

Re: [OSM-dev] tag implication database/library

[François Lacombe]

Hi Per Eric,

What you are looking for is definitely on the wiki side.

The information isn't available as described for now but it would be
interesting to document tags like this.
And a new application/projet might not be necessary if wiki can support it.


That question was rose a few times ago.

All the best

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

2016-11-17 11:51 GMT+01:00 Per Eric Rosén :

> Hi!
>
> I have been making a few maps and applications using OSM data, mostly
> stored in postgis. In all cases, I have had to make custom carto rules /
> database post-processing / application rules to compensate for multiple
> ways of expressing the same information in OSM. Also, in some cases,
> for taking care of which tag implies which information.
>
> Is there some way of doing this just once; for example with some parseable
> implication database, and library? There is some "implies" on the wiki; but
> it's not completely chine-readable in a reliable way.
>
> Such a database would probably also need being optionally keyed on
> country, "highway=cycleway" may imply different rules in different
> countries for example.
>
> Would such a tool/database be useful, if not existing already?
>
> I see two somewhat different usage cases, and I don't know if the same
> tool/database should be used for both:
>
> 1. normalizing a database before usage, for example changing
>"highway=ford" to "ford=yes" and moving to modern lifecycle tags
>
>(it could be argued that this shoud be done on the main OSM database
> by a bot, but data consumers could probably have larger or more
> specific needs of normalization compared to what can be agreed to do
> by changing the master OSM data)
>
> 2. getting specific implications without writing it to a database, for
>example highway=cycleway implies bicycle=yes, foot=yes in country X
>
> best regards
> Per Eric Rosén
> --
> ^): Per Eric Rosén http://rosnix.net/~per/
> /   p...@rosnix.net GPG 7A7A BD68 ADC0 01E1 F560 79FD 33D1 1EC3 1EBB 7311
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>
>
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] A PostgreSQL extension for real-time simplification of objects in OSM API database

[Jukka Rahkonen]

Martin Koppenhoefer wrote 2016-11-17 14:39:

2016-11-17 11:08 GMT+01:00 Rory McCann :


But... isn't there a danger that the mapper will load this
simplified/reduced object in JOSM (etc), change the tags, then press
upload? And then upload the simplified/reduced geometry? Which will
make
the OSM data worse?


there would have to be precautions, the editors supporting reduced
data download would have to take care that only unreduced data can be
edited and uploaded. Maybe the API-server restituting different ids
for reduced data could help here as well, so even if the data consumer
/ editor doesn't implement a special rule and someone tried to upload
simplefied data it would not overwrite the un-simplified OSM elements
or could be rejected.


There can be a need to make the features which are edited to match with 
other existing features. If those other features are reduced ones the 
result may not be what was expected. It may be hard to make this system 
reliable.


-Jukka Rahkonen-

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

Re: [OSM-dev] A PostgreSQL extension for real-time simplification of objects in OSM API database

[Martin Koppenhoefer]

2016-11-17 11:08 GMT+01:00 Rory McCann :

> But... isn't there a danger that the mapper will load this
> simplified/reduced object in JOSM (etc), change the tags, then press
> upload? And then upload the simplified/reduced geometry? Which will make
> the OSM data worse?
>


there would have to be precautions, the editors supporting reduced data
download would have to take care that only unreduced data can be edited and
uploaded. Maybe the API-server restituting different ids for reduced data
could help here as well, so even if the data consumer / editor doesn't
implement a special rule and someone tried to upload simplefied data it
would not overwrite the un-simplified OSM elements or could be rejected.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

[OSM-dev] tag implication database/library

[Per Eric Rosén]

Hi!

I have been making a few maps and applications using OSM data, mostly 
stored in postgis. In all cases, I have had to make custom carto rules /

database post-processing / application rules to compensate for multiple
ways of expressing the same information in OSM. Also, in some cases,
for taking care of which tag implies which information.

Is there some way of doing this just once; for example with some parseable 
implication database, and library? There is some "implies" on the wiki; 
but it's not completely chine-readable in a reliable way.


Such a database would probably also need being optionally keyed on 
country, "highway=cycleway" may imply different rules in different 
countries for example.


Would such a tool/database be useful, if not existing already?

I see two somewhat different usage cases, and I don't know if the same 
tool/database should be used for both:


1. normalizing a database before usage, for example changing
   "highway=ford" to "ford=yes" and moving to modern lifecycle tags

   (it could be argued that this shoud be done on the main OSM database
by a bot, but data consumers could probably have larger or more
specific needs of normalization compared to what can be agreed to do
by changing the master OSM data)

2. getting specific implications without writing it to a database, for
   example highway=cycleway implies bicycle=yes, foot=yes in country X

best regards
Per Eric Rosén
--
^): Per Eric Rosén http://rosnix.net/~per/
/   p...@rosnix.net GPG 7A7A BD68 ADC0 01E1 F560 79FD 33D1 1EC3 1EBB 7311___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] iD 2.0.0 always start in whole world view

[Grant Slater]

On 17 November 2016 at 10:39, joost schouppe  wrote:
> Another thing I noticed is that the "best imagery" is no longer loaded by
> default. Is there already an Issue for that?
> (example: in northern Belgium AGIV is marked as best and used to be loaded
> by default)
>

Yip, also a known issue: https://github.com/openstreetmap/iD/issues/3586

It will be fixed once iD v2.0.1 is released.

/ Grant

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

Re: [OSM-dev] iD 2.0.0 always start in whole world view

[joost schouppe]

Another thing I noticed is that the "best imagery" is no longer loaded by
default. Is there already an Issue for that?
(example: in northern Belgium AGIV is marked as best and used to be loaded
by default)

2016-11-17 0:39 GMT+01:00 Bryan Housel :

> Thanks markus!  we’re tracking this on https://github.com/
> openstreetmap/iD/issues/3588
> This is a bug in the code that hands off control from the
> openstreetmap-website code to iD which runs in an iframe..
>
>
> On Nov 16, 2016, at 6:26 PM, markus schnalke  wrote:
>
> Hoi,
>
> great that iD 2.0.0 already is available on osm.org! :-)
>
> But I encountered a problem: When I click on the ``edit with iD''
> link in keepright.at, the new iD 2.0.0 on osm.org does not (as
> before) zoom to the given location but always starts in the
> minimal zoom level, showing the whole world.
>
> The link in keepright.at for instance is:
> http://www.openstreetmap.org/edit?editor=id=48.5398992;
> lon=9.9190626=18=24340343
>
>
> meillo
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>
>


-- 
Joost @
Openstreetmap  |
Twitter  | LinkedIn
 | Meetup

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

Re: [OSM-dev] A PostgreSQL extension for real-time simplification of objects in OSM API database

[Rory McCann]

On 17/11/16 03:23, RTOSM DOOPAS wrote:
> 1. Initially, User opens JOSM/Potlatch to browse an overview map.
> currently the data are shown in slippy maps which are rendered from
> data to an imagery in advance at a rendering server. With rtosm, the
> overview map can be a collection of simplified objects to be rendered
> in client window. With this data, user can edit non-geometric part of
> the object, such as tags and relation members.

But... isn't there a danger that the mapper will load this
simplified/reduced object in JOSM (etc), change the tags, then press
upload? And then upload the simplified/reduced geometry? Which will make
the OSM data worse?

If you want to just edit the tags of large complicated objects, you
could use a special editor like Level0 or RawEditor? (Or write software
that makes the XML API call(s) yourself).




signature.asc
Description: OpenPGP digital signature
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev