Re: [osmosis-dev] Duplicate keys in replication diffs

[Stephan Knauss]

Hello Paul,

Thanks for tracking down and reporting this bug.

On 17.09.2020 01:22, Paul Norman via osmosis-dev wrote:

In changeset 90486873 a node was introduced with the tags

    
    k="shelter_type^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?" 
v="lean_to"/>


You did not mention: Have you already filed a bugreport against 
potlatch2? I think it was not intended to push this key.


Have you checked whether we have more unintended tagging like this in 
the database?
Taginfo has a report about potentially problematic characters, but it 
does not seem to consider control characters.

https://taginfo.openstreetmap.org/reports/characters_in_keys#problem

Stephan



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

Re: Preset support of alternative preset items

[Stephan Knauss]

On 17.08.2020 23:00, Simon Poole wrote:

> One of the frequent use of them in JOSM is for address and contact 
fields.

>
> This is semantically something totally different than suggesting an
> alternative preset item (because the current one might be a common
> mistagging, the alternative might  be a more specific object, etc). And
> because it is semantically different it should be presented differently.

I think I have an idea what you mean. So it would be an attribute 
describing the relation between two linked presets.


How about something like this:



with the relation being one of the attributes:

alternative: to link to a similar preset with different tags
companion: to link to a preset with tags often used in combination
modern: to link to a preset which is a more modern style of tagging for 
the same thing (eg public transport)
legacy: to link to a preset which is a legacy style of tagging for the 
same thing (eg public transport)



The "companion" is already linked frequently in the wiki in the 
Template:KeyDescription as "combination". The "alternative" would be 
covered by "seeAlso".


So we could have this reflected in the presets as well.

Stephan

Re: Preset support of alternative preset items

[Stephan Knauss]

On 17.08.2020 16:29, Simon Poole wrote:


Some of the recent patches to JOSMs default preset have included
 elements for what are essentially presets for "similar"
objects.

This would seem to be to me quite interesting information to capture,
however the specific unstructured way of handling this would seem to be
a bit sub-optimal. 


Can you elaborate a bit more in what way you wish this to be more 
structured?


It is there to list similar tags. Do you want to structure the level of 
"similarity"?



- add an attribute to the preset_link element, example >     


So what else besides "alternative" do you suggest?


- introduce a new element, example
         

I do not see the difference here.
besides "link" for generic links, this "preset_link" already is a link 
specific for alternative presets. What would a new one differentiate?




- introduce a new element as a container, example
All references to "similar" presets are already known by the presence of 
"preset_link". As you would have either one "alternatives" in case there 
are links, or zero if not, what is the benefit of another container level?


Stephan

[OSM-dev] Localize start_date tags (and similar)

[Stephan Bösch-Plepelits]

Hi!

I developed a Javascript module for localizing start_date (and similar)
tags:

https://github.com/plepe/openstreetmap-date-format

e.g. it can turn a value "~1920..1925-10" into "between c. 1920 and October
1925". when German locale is loaded: "zwischen ca. 1920 und Oktober 1925".

Currently only English and German are available (I don't speak other
languages well enough).

The library is already in use within OpenStreetBrowser, e.g. in the
category "Building age":
https://www.openstreetbrowser.org/#map=18/47.07159/15.43820=buildings-start_date
(read more about the latest update here: 
https://blog.openstreetbrowser.org/node/64)

If you are interested in using this library, it is available on npmjs:
https://www.npmjs.com/package/openstreetmap-date-format

If you are interested in contributing, e.g. to add further locales, go to
https://github.com/plepe/openstreetmap-date-format/blob/master/HOWTO_CONTRIBUTE.md

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,------.
| Stephan Bösch-Plepelits  ❤ code ❤ urbanism ❤ free software ❤ cycling |
| Projects:|
| > OpenStreetMap: openstreetbrowser.org > openstreetmap.at|
| > Urbanism: Radlobby Wien|
| Contact: |
| > Mail: sk...@xover.mud.at > Blog: plepe.at > Code: github.com/plepe |
| > Twitter: twitter.com/plepe > Jabber: sk...@jabber.at   |
| > Mastodon: @pl...@en.osm.town   |
`--'


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

[OSM-dev] Leaflet.TextPath: multicolor labels, auto-orientation, ...

[Stephan Bösch-Plepelits]

Hi!

As many OSM related maps use Leaflet and the Leaflet.TextPath plugin, you
might be interested to learn that I made some awesome changes to this
library.

Here is the pull request: 
https://github.com/makinacorpus/Leaflet.TextPath/pull/72

You can clone the master branch of my copy of the repository:
https://github.com/plepe/Leaflet.TextPath

I hope you enjoy this christmas present!

greetings,
Stephan

PS: My application OpenStreetBrowser will include these extensions soon!
-> https://www.openstreetbrowser.org/
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,--.
| Stephan Bösch-Plepelits  ❤ code ❤ urbanism ❤ free software ❤ cycling |
| Projects:|
| > OpenStreetMap: openstreetbrowser.org > openstreetmap.at|
| > Urbanism: Radlobby Wien|
| Contact: |
| > Mail: sk...@xover.mud.at > Blog: plepe.at > Code: github.com/plepe |
| > Twitter: twitter.com/plepe > Jabber: sk...@jabber.at   |
| > Mastodon: @pl...@en.osm.town   |
`--'


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

Re: JOSM developers meetup at Karlsruhe?

[Stephan Knauss]

As I started digging into UI hangs already, would be great to have a discussion 
regarding the thread pools and how they could interfere / block painting.

Stephan


On October 15, 2018 2:05:26 AM GMT+07:00, Vincent Privat 
 wrote:
>There are at least two tickets for which I'd like to get help:
>https://josm.openstreetmap.de/ticket/15229
>https://josm.openstreetmap.de/ticket/16082
>
>I was also thinking to start a major plugin cleanup projet. I think we
>have
>too many plugins and we should see how to reduce this number (inclusion
>in
>core, deletion or merging plugins together)
>
>Do you have something else in mind?
>
>
>Le dim. 14 oct. 2018 à 19:26, Michael Zangl
>
>a écrit :
>
>> Hi,
>>
>> are there any specific issues we will be working on those days?
>>
>> Michael
>>
>> On 03.09.2018 22:36, Vincent Privat wrote:
>> > Hello,
>> > I was thinking for quite some time about setting up a meeting
>between
>> JOSM
>> > developers somewhere in Germany (for convenience).
>> > As Christine and Frederik are inviting OSM developers to Karlsruhe
>on
>> > October 20th-21st, I just registered myself!
>> > Would other team members be interested? I'd love to meet everyone
>in
>> person!
>> > As for JOSM projects/activities for this hack week-end, there are
>plenty
>> of
>> > them to work on, it will depend on who's there :)
>> > Cheers,
>> > Vincent
>> >
>>
>>

Re: frozen editor while panning or zooming of the map

[Stephan Knauss]

On 14.09.2018 09:12, Dirk Stöcker wrote:

Hello Stephan,


Shall I create a ticket with the details up to now to better track it?


Yes. Please create a ticket and copy all relevant details there. 

created https://josm.openstreetmap.de/ticket/16734

Discussions in the mailinglist tend to be forgotten, the JOSM wiki is 
our main communication channel (as you can easily see when you look at 
the timeline :-).
I hoped the mailing list being a bit more interactive so to easier track 
down the issue.


Please let me know if any further details/reproduction are needed.

Thanks,

Stephan

Re: frozen editor while panning or zooming of the map

[Stephan Knauss]

On 11.09.2018 08:04, Stephan Knauss wrote:
The AWT Eventqueue looks a bit generic. YourKit can point to "Long AWT 
Events" in the "Threads" tab. I have for example one longer than 5s.


I stored a snapshot here. Can't shorten the timeline I think, but 
resetting telemetry caused only the last "long event" of 8s having call 
stacks I think.


http://downloads.osm-tools.org/josm-custom-2018-09-11(7).zip

I don't understand why the events tab does not have call stacks recorded.

It seemed that whenever I did not use JOSM for a few minutes because I 
scrolled around in the profiler or source and then go back to JOSM and 
zoom I got a wait. One time over 22 seconds.


Can someone more familiar with the profiler confirm that the AWT loop is 
not blocked but simply busy for that long?


Is it filling tasks to JCSCachedTileLoder.submit()?
I don't know how to limit the CPU analysis to that timeframe to see 
where the cycles go.


Stephan

Re: frozen editor while panning or zooming of the map

[Stephan Knauss]

Hello Michael,

On 10.09.2018 22:07, Michael Zangl wrote:
Tile loading should be in background. You can completely ignore those 
loader threads and need to focus on the AWT Event Thread instead. This 
is the thread that should not be blocked. It can be blocked by several 
things, e.g.:

* Synchronisation (waiting e.g. for a tile thread)
* Graphics rendering (filters / ...)
* Stop-the-world garbage collection


Thanks. This is also my understanding. I try to figure out where it 
blocks. With it being reproducible quite easy I hope to be able to 
contribute a meaningful analysis of the problem.


I just started with YourKit, but I worked with similar tools before. So 
hoping I get similar results from that one.


The AWT Eventqueue looks a bit generic. YourKit can point to "Long AWT 
Events" in the "Threads" tab. I have for example one longer than 5s.


What I not yet understand is, why the marked red bar of the event 
duration stretches much longer than the section where it prints a 
stack-trace.


It looks to be here:
org.openstreetmap.josm.gui.layer.AbstractTileSourceLayer$TileSet.visitTiles(Consumer, 
Consumer) AbstractTileSourceLayer.java:1293


which is:
   public void visitTiles(Consumer visitor, 
Consumer missed) {
tilePositions().parallel().forEach(tp -> 
visitTilePosition(visitor, tp, missed));

}


So it seems to be something with tile handling, which would be 
consistent to my assumption that it has something to do with tile loading.


I not yet fully understand the timeline view of the profiler here.
It lists two sections, one with "Sample duration" 900ms and one with 
5.200ms.


Are the ForkJoinPool.commonPool threads the one doing the parallel work?
Most of them are blocked on synchronized (paintMutex) in
org.openstreetmap.josm.gui.layer.AbstractTileSourceLayer.lambda$paintTileImages$2(List, 
Object, Graphics2D, Tile) AbstractTileSourceLayer.java:1027


What I not understand is when looking at the one in the pool working, it 
is drawing a tile:
org.openstreetmap.josm.gui.layer.AbstractTileSourceLayer.drawImageInside(Graphics2D, 
BufferedImage, TileAnchor, TileAnchor, Shape) 
AbstractTileSourceLayer.java:993


But I don't see that one consuming massive CPU. Think I have to re-check 
how to better record the profiler logs. Maybe sampling faster?


Is there any specific class or behavior you could point to with this 
(limited) level of information to further check?



Thanks,

Stephan

frozen editor while panning or zooming of the map

[Stephan Knauss]

Hello,

I sometimes suffer delays of 10-15s when panning or zooming the map.

I had the impression it started to become worse when tile serving was 
switched over to https, but switching back to http did not fully fix it.
With JOSM being updated in parallel all not that great to track down 
such issues. Just seeing in the terminal window large gaps between tile 
requests. Hiding imagery tiles always makes it fast. So it is certainly 
related.


So today I tried again to reproduce it, this time with YourKit Profiler 
connected.


I noticed some shorter delays, but couldn't fully reproduce the extreme 
delays.


Majority of time (about 60%) was spent in what I guess is tile loading:
HttpClient.java:91 
org.openstreetmap.josm.tools.HttpClient.connect(ProgressMonitor)


I have typically the two DG layers active sometimes also esri and bing 
to compare the images and alignment. With my large screen having 4k 
resolution, I might have a significant larger window visible than the 
average user.
I sometimes feared that mapbox might throttle the tile delivery. My 
connection itself is a fast 50 MBit link which typically is fast towards 
mapbox.


I then thought to make it a bit harder for JOSM and reduced the maximum 
connections per host down from 12 connections to 6 connections.


I got multiple seconds of frozen map now. After panning or zooming the 
view is frozen. Mouse still moves, but the line I am currently painting 
no longer follows the cursor. Just jumps back after five to ten seconds.


Now the majority of time is spent here:

HostLimitQueue.java:30 
org.openstreetmap.josm.data.cache.HostLimitQueue.poll(long, TimeUnit)


Can you please give some high-level explanation on how the GUI is 
connected to tile loading?


My expectation would be that tile loading happens in the background. In 
case of a blocked download (for whatever reason) my expectation would be 
that just the background tiles are not updated. panning, zooming or 
editing should not wait on it.
Is there a critical section somewhere which would be better not shared 
between the editor and tile loading?


How much personal details is recorded in the profiler snapshots? Would 
it help if I share one? Anyone more experienced interested in running a 
profiling session via skype?



If I read the call tree correctly, then below:
HttpClient.java:91 
org.openstreetmap.josm.tools.HttpClient.connect(ProgressMonitor)

the routines
HttpClient.java:149 <...> 
sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode()

and
HttpClient.java:149 <...> java.net.HttpURLConnection.getResponseCode()

use 40% of the time there. Do I get it right that this is only used for 
logging? Maybe only do this then in case log-level is at least info


### Eclipse Workspace Patch 1.0
#P JOSM
Index: src/org/openstreetmap/josm/tools/HttpClient.java
===
--- src/org/openstreetmap/josm/tools/HttpClient.java(revision 14108)
+++ src/org/openstreetmap/josm/tools/HttpClient.java(working copy)
@@ -144,13 +144,15 @@
 try {
 connection.connect();
 final boolean hasReason = reasonForRequest != null && 
!reasonForRequest.isEmpty();

-Logging.info("{0} {1}{2} -> {3}{4}",
-requestMethod, url, hasReason ? (" (" + 
reasonForRequest + ')') : "",

-connection.getResponseCode(),
-connection.getContentLengthLong() > 0
-? (" (" + 
Utils.getSizeString(connection.getContentLengthLong(), 
Locale.getDefault()) + ')')

-: ""
-);
+if (Logging.isLoggingEnabled(Logging.LEVEL_INFO)) {
+Logging.info("{0} {1}{2} -> {3}{4}",
+requestMethod, url, hasReason ? (" (" + 
reasonForRequest + ')') : "",

+connection.getResponseCode(),
+connection.getContentLengthLong() > 0
+? (" (" + 
Utils.getSizeString(connection.getContentLengthLong(), 
Locale.getDefault()) + ')')

+: ""
+);
+}
 if (Logging.isDebugEnabled()) {
 Logging.debug("RESPONSE: {0}", 
connection.getHeaderFields());

 }



Stephan

Re: [OSM-dev] OpenStreetBrowser: Improved public transport map and other route relations

[Stephan Bösch-Plepelits]

On Wed, Aug 08, 2018 at 09:24:22PM +0100, Dave F wrote:
> Could the bus data be split from the railways/
Yes, but I'm not planning to include this in main OpenStreetBrowser. In my
opinion all types of public transportation are connected (bus, tram, train,
ferry, subway, ...) and they all should appear on the same map.

But I have two solutions for you:

1. You are welcome to create your own version of the map. You can create a
copy of the public transport map and adapt it to your needs.
- Code:
  
https://www.openstreetbrowser.org/dev/OpenStreetBrowser/main/src/branch/master/pt.json
  If you start to edit it, it will be openened in a special editor.
- Instructions:
  https://wiki.openstreetmap.org/wiki/OpenStreetBrowser/Howto_Categories

2. I'm planning to introduce additional filters. Then you could filter by
   type of route. Or - for example in the Gastronomy category - by cuisine
   or type of gastronomy (bar, restaurant, cafe, ...). I can't tell you,
   when this feature will be implemented, maybe in the next few months.

greetings,
    Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,--.
| Stephan Bösch-Plepelits  ❤ code ❤ urbanism ❤ free software ❤ cycling |
| Projects:|
| > OpenStreetMap: openstreetbrowser.org > openstreetmap.at|
| > Urbanism: Radlobby Wien 15 |
| Contact: |
| > Mail: sk...@xover.mud.at > Blog: plepe.at > Code: github.com/plepe |
| > Twitter: twitter.com/plepe > Jabber: sk...@jabber.at   |
`--'


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

[OSM-dev] OpenStreetBrowser: Improved public transport map and other route relations

[Stephan Bösch-Plepelits]

Before starting my project OpenStreetBrowser (which was a long time ago
in autumn of 2008) I just wanted to create a public transport map
(short: PT map).  Creating a PT map is really difficult and creating a
usable map is even more difficult. There are several reasons for this,
including that OpenStreetMap itself adds a lot of complexity. But it is
possible. Back then, my efforts resulted in OpenStreetBrowser 1, but the
PT map code didn't last long.

History repeated itself 8 years later, as in autumn 2016 - at a time
after OpenStreetBrowser has been shut down - I made another attempt to
create a PT map (you can still see the result on ptmap.plepe.at). From
this code, OpenStreetBrowser 3 (the current version) was born - though
with very rudimentary support for route relations: All visible relations
would be loaded with their full geometries and displayed on top of each
other - regardless of their priority. Now, only the visible parts of
relations will be loaded once (even when they are part of several
relations) and shown with their relation memberships.

So, finally I can present another iteration of public transport maps,
this time included in OpenStreetBrowser:

Many things already work:
- Ways are colored by type of the route relations
- Popups of stops and ways show list of routes
- Separate lists for visible stops and visible routes
- Route popups and details show list of stops

Still, there are some missing features:
- Stops with the same name should be grouped and labeled.
- Directions of routes are not shown.
- Hide routes which are currently out of service (derived from the
  opening_hours tag).
- Take scale of route into account.
- In route view, stops are not named when the name has to be read from a
  stop_area relation.
- Performance optimizations.

-> https://openstreetbrowser.org/#categories=pt

Other route relations
-
As a by-product, also other route relations (cycle routes, hiking, ...)
are now much better supported.

The following categories have been improved / newly created:

- Leisure, Sport and Shopping -> Outdoor activities -> Mountain bike routes
-> https://openstreetbrowser.org/#categories=mtb-routes
- Transportation -> Walking -> Hiking routes
-> https://openstreetbrowser.org/#categories=hiking_routes
- Transportation -> Cycling -> Cycle routes
-> https://openstreetbrowser.org/#categories=cycle_routes
- Transportation -> Individual Traffic -> Road routes
-> https://openstreetbrowser.org/#categories=car_routes
- Infrastructure -> Railway -> Railway routes
-> https://openstreetbrowser.org/#categories=railway-routes

Please post ideas and bug reports to the Github issue page!
-> https://github.com/plepe/openstreetbrowser/issues

Find pictures on the blog:
-> https://blog.openstreetbrowser.org/node/52

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,------.
| Stephan Bösch-Plepelits  ❤ code ❤ urbanism ❤ free software ❤ cycling |
| Projects:|
| > OpenStreetMap: openstreetbrowser.org > openstreetmap.at|
| > Urbanism: Radlobby Wien 15 |
| Contact: |
| > Mail: sk...@xover.mud.at > Blog: plepe.at > Code: github.com/plepe |
| > Twitter: twitter.com/plepe > Jabber: sk...@jabber.at   |
`--'


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

[OSM-dev] Tileserver DNS problems

[Stephan Bösch-Plepelits]

Hi!

Apparently there are some DNS problems with the tile server for the default
tiles.

For a.tile.openstreetmap.org I get 'host not found'.

The DNS servers for openstreetmap.org are A, B and C.NS.BYTEMARK.CO.UK

 8< 
# nslookup
> server A.NS.BYTEMARK.CO.UK
Default server: A.NS.BYTEMARK.CO.UK
Address: 80.68.80.26#53
> a.tile.openstreetmap.org
Server: A.NS.BYTEMARK.CO.UK
Address:80.68.80.26#53

a.tile.openstreetmap.orgcanonical name =
tile.geo.openstreetmap.org.
> tile.geo.openstreetmap.org 
Server: A.NS.BYTEMARK.CO.UK
Address:80.68.80.26#53

Non-authoritative answer:
*** Can't find tile.geo.openstreetmap.org: No answer
 8< 

Also other users report, that they don't get tiles ...

Please fix!

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,------.
| Stephan Bösch-Plepelits  ❤ code ❤ urbanism ❤ free software ❤ cycling |
| Projects:|
| > OpenStreetMap: openstreetbrowser.org > openstreetmap.at|
| > Urbanism: Radlobby Wien 15 |
| Contact: |
| > Mail: sk...@xover.mud.at > Blog: plepe.at > Code: github.com/plepe |
| > Twitter: twitter.com/plepe > Jabber: sk...@jabber.at   |
`--'


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

[OSM-dev] OpenStreetBrowser: Create or improve categories yourself

[Stephan Bösch-Plepelits]

Hi!

Many of you maybe don't know OpenStreetBrowser. Many might think it does no
longer exist, since I cancelled the project some time ago. Good news: Since
last summer it's alive again, with a totally new code base.
-> https://www.openstreetbrowser.org/

The newest update: You can create or improve categories yourself!

See the blog post for details: https://blog.openstreetbrowser.org/node/51

Check this little howto:
https://wiki.openstreetmap.org/wiki/OpenStreetBrowser/Howto_Categories

Have fun!

greetings,
    Stephan

PS: Bug reports and suggestions are very welcome. Best place:
https://github.com/plepe/openstreetbrowser/issues
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,--.
| Stephan Bösch-Plepelits  ❤ code ❤ urbanism ❤ free software ❤ cycling |
| Projects:|
| > OpenStreetMap: openstreetbrowser.org > openstreetmap.at|
| > Urbanism: Radlobby Wien 15 |
| Contact: |
| > Mail: sk...@xover.mud.at > Blog: plepe.at > Code: github.com/plepe |
| > Twitter: twitter.com/plepe > Jabber: sk...@jabber.at   |
`--'


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

[OSM-dev] Parts of Styria (Austria) are flooded

[Stephan Bösch-Plepelits]

http://www.openstreetmap.org/#map=15/47.0711/15.9890

Shouldn't look like this ...

Can anybody find the reason, maybe a broken multipolygon?

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,--.
| Stephan Bösch-Plepelits  ❤ code ❤ urbanism ❤ free software ❤ cycling |
| Projects:|
| > OpenStreetMap: openstreetbrowser.org > openstreetmap.at|
| > Urbanism: Radlobby Wien 15 |
| Contact: |
| > Mail: sk...@xover.mud.at > Blog: plepe.at > Code: github.com/plepe |
| > Twitter: twitter.com/plepe > Jabber: sk...@jabber.at   |
`--'


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

[OSM-dev] My new project: PTMap

[Stephan Bösch-Plepelits]

Hi!

You might be interested to have a view on my new OpenStreetMap project:
PTMap - a public transport map. Runs 100% in the browser, uses Overpass API
as database (I hope that overpass-api.de won't overload as a result).

-> https://ptmap.plepe.at

Have fun!

greetings,
    Stephan

PS: Find the source at https://github.com/plepe/ptmap
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,--.
| Stephan Bösch-Plepelits  ❤ code ❤ urbanism ❤ free software ❤ cycling |
| Projects:|
| > OpenStreetMap: openstreetmap.at > openstreetbrowser.org > pgmapcss |
| > Urbanism: Radlobby Wien 15 |
| Contact: |
| > Mail: sk...@xover.mud.at > Blog: plepe.at > Code: github.com/plepe |
| > Twitter: twitter.com/plepe > Jabber: sk...@jabber.at   |
`--'


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

Re: [OSM-dev] Tileserver User-agent

[Stephan Knauss]

Google​comes up with an app of this name. According to the presentation it 
displays OSM 

https://www.slideshare.net/mobile/Campesino_Asb/the-splendor-of-iphone-app-geographica

Stephan 

On September 24, 2016 9:56:39 PM GMT+02:00, yvecai <yve...@gmail.com> wrote:
>Hi there,
>
>Out of curiosity, does anybody know this user-agent:
>"geographica/1.1.35.0".
>
>Must be some kind of software using map tiles, but googling such a 
>common name is not the best way to contact them.
>
>Yves
>
>
>
>
>
>___
>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: [osmosis-dev] new dependency

[Stephan Knauss]

On 17.02.2016 08:19, Bas Couwenberg wrote:

On 2016-02-17 08:11, Stephan Knauss wrote:

Just a heads up: if you are following the latest revision you need to
install a new library.



Why does a Java program require a Python module?


please ignore this mail. It was intended to go to the osmos*e* list, not 
osmos*is*.


I did not properly check the autocomplete of the address and have missed 
it addressed the wrong one. Sorry for the noise.


Stephan


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

Re: [OSM-dev] Any JOSM developers/expert able to have a look at this login problem?

[Stephan Knauss]

Your email client seems to be intercepted by your Antivirus (quite intrusive) . 
Can you disable all protection to ensure that it is not hijacking your Internet 
connection and prevents JOSM from sending passwords...
Could explain why the OSM api doesn't receive your password and fails to 
authenticate. 



On February 11, 2016 4:38:56 PM GMT+01:00, Dave F  
wrote:
>Hi
>
>I've a JOSM login problem. I've posted the details here:
>
>https://help.openstreetmap.org/questions/48014/josm-enter-credentials-for-osm-api-failure
>
>If you've a few minutes to see if you can find the problem I'd 
>appreciate it.
>
>Thanks
>Dave F.
>
>---
>This email has been checked for viruses by Avast antivirus software.
>https://www.avast.com/antivirus
>
>
>___
>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] changes in coastline are not rendered

[Stephan Knauss]

On 09.02.2016 11:21, Oleksiy Muzalyev wrote:

On the other hand, I am in doubt, - perhaps, people invested a lot of
time and labor in clicking these hundreds and hundreds of nodes, to make
a nice looking map, and I am not sure if I am doing the right thing with
the tool SHIFT+Y (Simplify Way). Maybe this excessive number of nodes is
negligible for the database and rendering?


This is the reason I suggest against using the simplify functionality. 
Just because some detail level is not to your liking you sort of "tell 
off" those mappers who invested a lot of time putting that details in 
the first place when deleting it.


There are special situations where it can be useful, but in case of 
"hand-drawn" data mostly it is fine to go forward with a handful of 
additional nodes. And don't worry about the size of the data. Those few 
nodes don't do much harm (we have 4 billions already).


Stephan


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

Re: [josm-dev] SunCertPathBuilderException

[Stephan Knauss]

Dirk Stöcker writes:

Cert chain is/was complete. It seems Java still does not include StartSSL,  
but Unix versions and browsers use the system certstore. So standalone  
non-Unixes fail. All others work.


probably you wanted to say WOsign here, but yes, neither that, nor Startcom  
nor IdenTrust (for Let's Encrypt) is included in the Java store.


Just to have it as a reference in the mailing list archives: In the support  
forum Let's Entrypt said they had applied to be included in Oracles cacert  
list. So hopefully for the next renewal we'll have a better alternative.


https://community.letsencrypt.org/t/will-the-cross-root-cover-trust-by-the- 
default-list-in-the-jdk-jre/134/11


This is the command to dump the contents of the certificate store to see  
whether a specific CA is included.


"C:\Program Files (x86)\Java\jre1.8.0_66\bin\keytool.exe" -keystore "c: 
\program files (x86)\java\jre1.8.0_

66\lib\security\cacerts" -storepass changeit -list -v

Stephan

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

Re: [josm-dev] SunCertPathBuilderException

[Stephan Knauss]

On 15.12.2015 08:20, Dirk Stöcker wrote:

Seems Java with Windows 7 does not work, Java with Windows 7 in browser
works. Then we have to wait until Windows 7 dies to use it and renew
Globalsign.


the last report pointed to a quite recent configuration:
Identification: JOSM/1.5 (9060 en) Windows 10 64-Bit
Java version: 1.8.0_66, Oracle Corporation, Java HotSpot(TM) Client VM

It is the latest java version on the latest version of windows.

I hadn't checked the certificate store yet, but could it be that the 
server has to include an intermediate certificate? So not the complete 
chain is delivered? This would explain the failure.


https://www.wosign.com/English/support/SSLins/Apache_ins.htm


Stephan



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

[OSM-dev] new planet file?

[Stephan Bösch-Plepelits]

Hi!

I wonder what happened to the weekly planet file? The last dates to June
24th, which is already two weeks old? Usually the new planet arrives on
Wednesday around noon.

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

[OSM-dev] pgmapcss version 0.10.0

[Stephan Bösch-Plepelits]

Read this on the blog: http://pgmapcss.openstreetbrowser.org/blog/?p=59

The new version 0.10 brings a new database backend, which also became the new
default: Overpass API. The main advantage is, that no local OpenStreetMap
database import is necessary, as (by default) the public API at overpass-api.de
is used. A local database is needed nonetheless (e.g., for access to the
PostGIS functions, caching, and connecting to Mapnik). The background rendering
of the OpenStreetBrowser[1] is already using the new Overpass backend (with a
local Overpass installation). For details about the database backends see the
file database.md[2].

[1] http://openstreetbrowser.org/
[2] https://github.com/plepe/pgmapcss/blob/master/doc/database.md

Most other changes were “under-the-hood”, e.g. the database backend access has
been re-structured and documented, the osm2pgsql database backend can optimize
some relationship queries and so on. See the CHANGELOG[3] file for details or
the git log[4].

[3] https://github.com/plepe/pgmapcss/blob/master/CHANGELOG.creole
[4] https://github.com/plepe/pgmapcss/compare/v0.9.0...v0.10.0

Get the source here: https://github.com/plepe/pgmapcss/releases/tag/v0.10.0

For the next version there are already some interesting features in queue. Most
importantly, I’m planning to process the objects partly parallel, so that an
object may read changed values of a related feature (either because of
parent-child relation or by geographic proximity). See issue #102[5] for
details and progress.

[5] https://github.com/plepe/pgmapcss/issues/102

Have fun with the new version.

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

Re: [OSM-dev] Release openstreetmap-carto v2.25.0

[Stephan Knauss]

For my Thai style adjustments I wish for more style files. This reduces the 
chance of merge conflicts. 

Also having font sizes in one place to be able to bump it up easily by 2 points 
would be great. 

Stephan 

On December 18, 2014 8:43:00 PM GMT+07:00, Andy Allan gravityst...@gmail.com 
wrote:
On 11 December 2014 at 15:34, Sven Geggus li...@fuchsschwanzdomain.de
wrote:

 BTW, I'm also still looking for a less annoying way to maintain the
german
 style which is basically a fork of your style starting from various
versions.

Please do let me know if there's anything we can do to
openstreetmap-carto to make this easier for you, even if it's just a
small change.

Cheers,
Andy

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

[OSM-dev] pgmapcss version 0.9.0

[Stephan Bösch-Plepelits]

Read this text on the blog:
http://pgmapcss.openstreetbrowser.org/blog/?p=48
pgmapcss:https://github.com/plepe/pgmapcss

When I attended SOTM-EU in Karlsruhe this year, I was asked by a member of the
Osmose project, if pgmapcss could be used as tool for quality assurance. JOSM
earlier introduced MapCSS based rules[1] for checking possibly incorrect tags
in OpenStreetMap data. Sure, it was possible with pgmapcss – it just needed a
few adaptions. The main challenges were to rewrite the output to a machine
readable format and to use a different database layout (osm2pgsql does not
import the full database, but only features with certain tags).

[1] https://josm.openstreetmap.de/wiki/Help/Validator/MapCSSTagChecker

Machine readable format
---
Graphical rendering is not the best possible solution, that’s why having
machine readable output is more reasonable. I introduced a second frontend,
“standalone”: The MapCSS stylesheet is compiled into a python script, which can
then be run from the command line or as CGI script. The script will produce
GeoJSON output.

When testing, this proved to be very powerful, I also implemented a web-based
frontend[2] for pgmapcss using OpenLayer 3.0 as feasibility study.

There’s an example GeoJSON output in the README[3].

[2] https://github.com/plepe/ol4pgm
[3] https://github.com/plepe/pgmapcss/blob/master/README.md

Changes in database backend(s)
--
As second database backend, the pgsnapshot layout from Osmosis is now
supported.  The main benefit is the completeness of the database, but there are
more advantages (there are disadvantages too), e.g. meta information for the
map features (like who edited the feature last, when was the last change, and
so on). This information is available as pseudo tags: “osm:id”, “osm:user”,
“osm:user_id”, “osm:changeset”, “osm:timestamp”, “osm:version”. There’s even an
option to use multipolygons using osmosis-multipolygon[4].

The standard “osm2pgsql” backend also got an update. Now it does no longer
require the existence of the “tags” column, but rather uses the table columns
if available. It will detect the database layout automatically, but you can
influence behaviour using configuration options. The pseudo tag “osm:id” is now
also set.

pgmapcss now generates improved SQL selects, especially for conditions with
e.g. regular expressions, prefix/suffix matches, …

For more details see the database documentation[5].

[4] https://github.com/plepe/osmosis-multipolygon
[5] https://github.com/plepe/pgmapcss/blob/master/doc/database.md

Additional features
---

* Localization support. There’s certain support for languages, read the
  corresponding chapter in the README.
* Drastically reduced memory consumption.
* New debugging options, see configuration options[6].

[6] https://github.com/plepe/pgmapcss/blob/master/doc/config_options.md

Other
-
* The background rendering of OpenStreetBrowser[7] now uses a pgmapcss based
  style[8].

[7] http://openstreetbrowser.org/
[8] https://github.com/plepe/OpenStreetBrowser-basemap

Have fun!
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

[OSM-dev] Multipolygon support for Osmosis pgsnapshot

[Stephan Bösch-Plepelits]

In my opinion, one of the biggest disadvantages of the pgsnapshot schema of
Osmosis (compared to e.g. osm2gpsql) is the missing multipolygon support.

Years ago I created scripts for the OpenStreetBrowser, based on a pgsimple
import (pgsnapshot was not yet available at that time), for multipolygon
support and derivative tables. Those scripts were never released separately
and therefore nobody knows about them (I guess).

Now, I just adapted them to the pgsnapshot schema and Postgis 2.0 and
concentrated on the multipolygon support (no derivative tables any more)
and released them as separate repository:
https://github.com/plepe/osmosis-multipolygon

After an initial osmosis pgsnapshot import, you load those scripts and they
will create a simple 'multipolygons' table with the columns: ( relation_id,
tags, geometry ). If you use replication to keep your database up-to-date,
the 'multipolygons' table will also update (the scripts overwrite the
osmosisUpdate() function).

Have fun!

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

[OSM-dev] pgmapcss version 0.8.0

[Stephan Bösch-Plepelits]

During this version update I mostly concentrated on compatibility with
JOSM, but there were also some major performance improvements. Also, Mapnik
3.0 support improved, as features were added in Mapnik source code.  It is
a huge update with more than 250 commits.

JOSM has many features beyond the MapCSS 0.2 specification. pgmapcss now
supports most of those features, therefore you can render many JOSM styles
with Mapnik.

The most important changes:
* You can use @media queries to skip certain style rules under specific
  conditions, most likely the currently used renderer.
* Select objects (mostly ways) depending whether there’s right or left hand
  traffic in this region, either as pseudo class :righthandtraffic or eval
  function: is_right_hand_traffic().
* New properties, including: symbol-, repeat-image-, left-casing-,
  right-casing-, dashes-background-color, text-anchor-, icon-rotation, …
* Additional condition selectors, including: truth/false value
  [tag?][tag?!], presence of tag by regular expression: [/^addr:/].
  Pseudo classes like :tagged, :connected, …. Negate classes and pseudo
  classes: !.class, !:pseudo_class.
* Link selectors: ∈, ∋, ⧉: within, surrounds, overlaps
* Many new eval functions including trigonometric functions, color
  functions, …

If you compile JOSM styles, you should pass the option --defaults josm,
which changes default values and enables additional features. There were
some more compiler arguments added, see pgmapcss --help for details.

Also, pgmapcss got a blog: http://pgmapcss.openstreetbrowser.org/blog/
Find the source code at: https://github.com/plepe/pgmapcss

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

[OSM-dev] mod_tile not respecting config value

[Stephan Knauss]

Hello,

I have a rendering stack with mod_tile/tirex which works quite fine.
Now I discovered that tiles which do not exist at all and take longer to 
render will return a 404 after 3 seconds.


This is surprising to me as I have in apache's mod_tile.conf the 
following settings:



# Timeout before giving up for a tile to be rendered
ModTileRequestTimeout 3

# Timeout before giving up for a tile to be rendered that is otherwise 
missing

ModTileMissingRequestTimeout 30



With these setting I would have expected that the timeout is 30 seconds 
for tiles which do not exist at all and be only 3 seconds for requests 
where some older (outdated) tile exists.




I enabled a higher verbosity level and got this in apache logs 
(shortened to the relevant info):


Requesting style(s2) z(7) x(39) y(73) from renderer with priority 5
request_tile: Request xml(s2) z(7) x(39) y(73) could not be rendered in 
3 seconds
tile_storage_hook: Missing tile was not rendered in time. Returning File 
Not Found


So why is mod_tile using a timeout of 3 seconds and not 30 seconds?

More confusing: After I inserted the mentioned two lines into my 
VirtualHost config section which handles the rendering mod_tile is 
working as expected.


Does this indicate that the way global settings are handled by mod_tile 
is broken? Might it indicate that my other settings are not effective as 
well?


Should I open a bug report for it? At GitHub?

Stephan

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

Re: [OSM-dev] OSM data import using osm2pgsql... what's next.

[Stephan Bösch-Plepelits]

On Sat, Aug 02, 2014 at 11:52:58AM +0100, Éric Gillet wrote:
  On Sat, Aug 2, 2014 at 9:52 AM, Christian Quest cqu...@openstreetmap.fr
  wrote:
  By default osm2pgsql reprojects into web mercator, but you can avoid it
  and ask to keep the spherical coordinates if this is a better choice for
  your use.
 May I ask how to use spherical coordinates ? I've hit the problem about
 distances being distorded with projections, and never managed to do it
 right with osm2pgsql based db.
Distance between Berlin and London:

select ST_Distance(Geography(ST_GeometryFromText('POINT(13.3888598981363
52.517036494754)')), Geography(ST_GeometryFromText('POINT(-0.127647399982231 
51.5073218947764)')))
- 933410.764104169 m

If you have the coordinates in spherical mercator, you need to reproject
them to WGS-84, using:

select name, way from planet_osm_point where osm_id='240109189'; -- Berlin
- Berlin | 01012031BF0D001C0FF01009BE3641B969376A934C5A41

select name, ST_astext(way) from planet_osm_point where osm_id='240109189';
- Berlin | POINT(1490441.06616301 6894157.65963214)

select name, ST_astext(ST_Transform(way, 4326)) from planet_osm_point where 
osm_id='240109189';
- Berlin | POINT(13.3888598981363 52.517036494754)

select name, ST_astext(Geography(ST_Transform(way, 4326))) from 
planet_osm_point where osm_id='240109189';
- Berlin | POINT(13.3888598981363 52.517036494754)
(same as before, but can be used to make projected calculations)

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

[OSM-dev] strange error message from mod_tile

[Stephan Knauss]

Hi,

I've set up a new machine with a mod_tile / Tirex rendering stack.

I see some strange errors in the log file which I don't understand. Any 
help would be appreciated.


I can reproduce it when requesting a tile image considered dirty.
The rendering itself looks fine. For example loading the tile as /dirty 
will trigger a rendering which is visible in tirex-status.


Requesting the image as image will not trigger a rendering. It produces 
strange log lines.


Here are the log lines (shortened for readability):

[tile:debug] ./src/mod_tile.c(1381): tile_translate: op(tile_serve) 
xml(osm) mime(image/png) z(14) x(12612) y(7238)
[tile:info] tile_storage_hook: handler(tile_serve), 
uri(/osm/14/12612/7238.png)
[tile:debug] ./src/mod_tile.c(365): tile_state: determined state of osm 
12612 7238 14 on store 7fbe01e40a60: Tile size: 7124, expired: 1 
created: 1404246259
[tile:debug] ./src/mod_tile.c(166): Connecting to renderd on Unix socket 
/var/lib/tirex/modtile.sock
22:03:21.814464 [tile:info] Requesting style(osm) z(14) x(12612) y(7238) 
from renderer with priority 7
22:03:21.815113 [tile:warn] request_tile: Failed to read response from 
rendering socket No such file or directory


So mod_tile was able to open the socket.
The select() call returned immediately.

But then an error is reported.

Can I trust errno in this situation? I only know that recv() did not 
return the expected number of bytes.



Having tirex-master running in debug mode also gives no clue what's 
happening. I see the request being received.
tirex-master[32229]: Listening for commands on socket 
/var/run/tirex/master.sock
tirex-master[32229]: Listening for mod_tile connections on 
/var/lib/tirex/modtile.sock (UNIX)

tirex-master[32229]: Listening for backend responses
tirex-master[32229]: connection from mod_tile accepted
tirex-master[32229]: read request from mod_tile: ver=2 cmd=7 x=12612 
y=7238 z=14 map=osm


Stephan

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

Re: [OSM-dev] strange error message from mod_tile

[Stephan Knauss]

Hi,

answering myself in case others run into the same problem and find it in 
the archive.


On 06.07.2014 23:15, Stephan Knauss wrote:

I see some strange errors in the log file which I don't understand. Any
help would be appreciated.

22:03:21.814464 [tile:info] Requesting style(osm) z(14) x(12612) y(7238)
from renderer with priority 7
22:03:21.815113 [tile:warn] request_tile: Failed to read response from
rendering socket No such file or directory


Issue was caused by mod_tile sending the unknown command id 7 
(cmdRenderLow) to tirex.


This was added by Kai in August 2013
Add another priority level (RenderLow) to accommodate rerenders after 
style changes


In addition to Render and RenderPrio, add another priority level of 
RenderLow.

https://github.com/openstreetmap/mod_tile/commit/1b4c56d8eda631179b5d03e8472e981425eb1a5f


As this command was unknown to tirex it failed to create a job and 
returned an error.


My perl is quite limited. I have no idea why I did not see any message 
of this line:
Carp::croak(need prio for new job)unless (defined 
$self-{'prio'});


Still issue was clearly the missing priority due to the command being 
out of bounds.


This command is now given a priority (25) below bulk as a completely 
expired planet is one of the worst things that can happen from a 
renderer perspective. Default tirex puts these in the background queue.



Fix tested and submitted.
https://trac.openstreetmap.org/changeset/30510/subversion/applications/utils/tirex

Stephan


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

Re: [OSM-dev] tirex and mapnik 3, make deb fails

[Stephan Knauss]

Jan-Benedict Glaw writes:


On Tue, 2014-07-01 01:58:38 +0200, Stephan Knauss o...@stephans-server.de 
wrote:

I try to compile tirex (mapnik backend) against Mapnik 3.
changing this line in debian/rules allowed me to ignore the error:
dh_shlibdeps --dpkg-shlibdeps-params=--ignore-missing-info


Won't work: A dep is missing and the resulting program will only run
IFF the user has the lib already installed.


So in my case this is perfectly fine. As I'm installing for a local machine  
where mapnik is also build.
Mapnik 3 is not yet released and based on mapnik mailing list advise it's  
better compiled directly from git instead of using some (outdated?) nightly  
build from a ppd. So no packages available.



The reason of doing a make deb instead of make install is the update  
path.
I once made the mistake in the past and upgraded tirex to a new version to  
have access to bugfixes. The make install was simply overwriting already  
existing configuration files.
Frederik or Jochen recommended using the deb package method for updates as  
it should take care for changes in already existing config files.


So I worry a bit about the version information in the package. Is a newer  
build automatically recognized as a newer package? Does the build process  
create this version information?


Honestly I'm just interested in getting an upgradeable tirex to the new  
machine. Learning all this stuff about debian package creation and fix the  
tirex build environment is certainly also an interesting topic but not the  
task I wanted to do now. For someone experienced in debian packaging it is  
certainly just a few minutes to check this and suggest a proper fix to the  
build environment.


Stephan

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

Re: [OSM-dev] tirex and mapnik 3, make deb fails

[Stephan Knauss]

Sven Geggus writes:


Stephan Knauss o...@stephans-server.de wrote:


Is a newer build automatically recognized as a newer package?

No, use dch -i


The last entry in tirex's debian/changelog is more than two years old. So  
its quite safe to assume that upstream changes will not result in new  
debian/ubuntu versions.


Could the build-process be adapted to always run dch -i before building a  
package?

Then the workflow to get updated tirex would be
svn up, build package, install package


Stephan

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

[OSM-dev] MapCSS proposals

[Stephan Bösch-Plepelits]

Hi!

I'd like to initiate the extension of the current MapCSS standard. I think
MapCSS has great potential, but for really powerful styles some additions
are necessary. Surely they also need to be supported by the libraries, but
it's better to discuss the standard first, before the libraries become
incompatible.

As I don't think that the talk page of MapCSS/0.2 as well the mailinglist
are good places to develop extensions, I took the procedure in the OSM Wiki
as an example and created a few proposals.

See here:
http://wiki.openstreetmap.org/wiki/Category:MapCSS_Proposal

Please have a look and say what you think.

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

[OSM-dev] tirex and mapnik 3, make deb fails

[Stephan Knauss]

I try to compile tirex (mapnik backend) against Mapnik 3.
All done on ubuntu 14.04.

Unfortunately it fails.

make runs fine, but doing make deb after that produces errors.

First problem was that it complained to not find mapnik-config.
After patching the Makefile to contain the results of the mapnik-config  
call it successfully continued to break at another step.


I have no idea about debian package creation. Can someone suggest a patch  
to resolve this issue?

Sounds like it does not like I did make  make install on mapnik

changing this line in debian/rules allowed me to ignore the error:
dh_shlibdeps --dpkg-shlibdeps-params=--ignore-missing-info

does it matter that the packages have this version id in the name?  
_0.4.1precise1_

Will it conflict with my ubuntu setup which is trusty?

Log:

dh_shlibdeps
dpkg-shlibdeps: error: no dependency information found for  
/usr/local/lib/libmapnik.so.3.0 (used by debian/tirex-backend- 
mapnik/usr/lib/tirex/backends/mapnik)
dh_shlibdeps: dpkg-shlibdeps -Tdebian/tirex-backend-mapnik.substvars  
debian/tirex-backend-mapnik/usr/lib/tirex/backends/mapnik returned exit  
code 2

make: *** [binary-arch] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit  
status 2

debuild: fatal error at line 1364:
dpkg-buildpackage -rfakeroot -D -us -uc -I failed
make: *** [deb] Error 29

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

Re: [OSM-dev] OSM software repositories -- git and svn

[Stephan Bösch-Plepelits]

On Tue, Jun 03, 2014 at 06:12:44PM -0700, Paul Norman wrote:
 Whenever I weigh the positives and negatives of using Github, I
 always come out in favor of using it.
Yeah, the workflow with Github is really awesome. I like it too.

There's an alternative though, which we are starting at my place of work
now: Gitlab, which is like an open source clone of Github. You can actually
run it yourself: https://www.gitlab.com/

Maybe OSM should run it?
Maybe it would be even possible to connect it to the OSM authentication?

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

[OSM-dev] pgmapcss version 0.7.0

[Stephan Bösch-Plepelits]

Hi!

Finally, there's a new release of pgmapcss - a MapCSS implementation for
Mapnik.

What's new?

The main improvement is that pgmapcss will try to guess the possible
results of eval()-statements, therefore it's now possible to use
calculations for properties which have to be predictable at compile-time
- which are most properties when using Mapnik 2.x, e.g. width and color.

There are more improvements, e.g. an included icon set (from the Mapbox
Maki project), the possiblity to mix MapCSS code with normal Mapnik
layers, CSS3 color names, eval()-selectors, ...
For a full list see the CHANGELOG file:
https://github.com/plepe/pgmapcss/blob/master/CHANGELOG.creole

About pgmapcss:

* I gave a talk about MapCSS in general and pgmapcss in particular at
  the Linuxwochen 2014 in Vienna. There's no video, but you can look at
  the slides (sorry, German - but there are many images and links):
  https://cfp.linuxwochen.at/de/LWW14/public/events/152

* There will be a talk about pgmapcss at the upcoming SOTM-EU conference
  in Karlsruhe: http://sotm-eu.org/en/slots/6

* There's a demo site at http://pgmapcss.openstreetbrowser.org/
  Don't overstress it :-)

* A fully working basemap style:
  https://github.com/plepe/OpenStreetBrowser-basemap

Grab/Fork the code at https://github.com/plepe/pgmapcss

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

Re: [OSM-dev] historical user names in full history dump

[Stephan Knauss]

On 07.03.2014 23:38, Tom Hughes wrote:

On 07/03/14 22:12, Stephan Knauss wrote:


I noticed that in the full history dump the user names associated with a
specific version does not match with the username which was active at
that time.


Well as we have no record of what the username was at the time of the
edit I'm not sure what else you would expect us to do?


Looks like Ilya missed similar information. He recreated it from the 
changesets:

https://lists.openstreetmap.org/pipermail/talk/2013-January/065897.html

What makes me wonder: The API .../history call also returns only the 
current user name.

This is in contrast to the problem Ilya described.
I'm also certain that before the license change I had code to deal with 
changed usernames when parsing planet files (regular, not full history).


So it sounds a bit someone thought about it and it's an intentional 
decision to treat the display_name volatile.
Was the API internals changed to use the uid more often instead of the 
display_name?


Is the problem described by Ilya maybe solved already? Will all data 
coming from the API and in current dumps have only the latest 
display_name set, so uid to name is a 1:1 relation?


Then I agree, having a history of display_names has little practical use.

Stephan


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

[OSM-dev] historical user names in full history dump

[Stephan Knauss]

I noticed that in the full history dump the user names associated with a 
specific version does not match with the username which was active at 
that time.


So a user with name A doing an edit in 2012 and then changing the 
username to B in 2014 is now listed with B for all edits, even those 
done in 2012 as A.


Is this intentional or just happened because nobody thought about it 
when creating the dump?
To reflect the actual history, I would have expected to see historical 
user names as well. History query of OSM API returns only current 
username as well.
As we have already a unique reference -the uid- why is the name changed 
in history and dump?


I have documented the current situation in the wiki so others won't 
wonder. Still interested: What would have been the intended behavior?


Slightly related to this:
https://github.com/Zverik/whosthat
https://trac.openstreetmap.org/ticket/4671
https://josm.openstreetmap.de/ticket/8251

Stephan

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

Re: [OSM-dev] OSM2PGSQL in slim mode

[Stephan Knauss]

Amir Pourabdollah writes:


Yes I apply updates on UK only. What I do is that I first apply the planet
update then remove the non-UK features from the ³main tables, perhaps I
should remove the non-UK features from the temporary tables too(?)


I'm also applying partial updates. The cleanup I outlined here work for me.  
No unexpected database growth visible.


http://wiki.openstreetmap.org/wiki/User:Stephankn/knowledgebase#Cleanup_of_w 
ays_outside_the_bounding_box


Stephan

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

[OSM-dev] pgmapcss version 0.5

[Stephan Bösch-Plepelits]

Hi!

After 3 months there's finally a new release: version 0.5.0.
Find the code here: https://github.com/plepe/pgmapcss

It is a major rewrite of the parser, the compiler and the mapnik
preprocessor. The former versions were mainly in plpgsql (the PostgreSQL
database procedure language) with some Shell and Perl code where plpgsql
was not appropriate (e.g. for file system access, which is not possible
from the database).

Now, all these parts have been re-written in Python3. Only some support
functions, e.g. for database queries and the eval functions remain. Also,
the mapcss stylesheets compile to plpgsql functions.

There were also some optimizations which I actually did before the rewrite
- I think I should have released a version 0.4.1 at that time.

For more information about the release check the CHANGELOG[1] file. Also,
check the installation instructions in [2]. Please report isses on [3].

[1] https://github.com/plepe/pgmapcss/blob/master/CHANGELOG.creole
[2] https://github.com/plepe/pgmapcss/blob/master/doc%2Finstall.md
[3] https://github.com/plepe/pgmapcss/issues

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

Re: [OSM-dev] mapnik-render-image 0.3 (was: generate_image.py)

[Stephan Bösch-Plepelits]

On Tue, Nov 26, 2013 at 11:28:10AM +, Andy Allan wrote:
 On 25 November 2013 22:03, Stephan Bösch-Plepelits
 sk...@xover.htu.tuwien.ac.at wrote:
 
  Now I renamed the script to 'mapnik-render-image' and renamed the project
  on Github accordingly:
  https://github.com/plepe/mapnik-render-image
 How does your new version of the script compare to the nik2img.py utility?
What a surprise, I didn't know this script exists. I searched on Google for
similar scripts but didn't find any.

Anyway, there is quite some functionality in nik2img which is missing in
mapnik-render-image. I will merge those scripts for the next
version.

Thanks for pointing me to nik2img!

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

Re: [OSM-dev] mapnik-render-image 0.3 (was: generate_image.py)

[Stephan Bösch-Plepelits]

Hi!

Lately I posted that I improved the generate_image.py script from
OpenStreetMap SVN:
https://lists.openstreetmap.org/pipermail/dev/2013-November/027548.html

Now I renamed the script to 'mapnik-render-image' and renamed the project
on Github accordingly:
https://github.com/plepe/mapnik-render-image

I decided to introduce versioning, starting with 0.1 for the original
generate_image.py script and 0.2 my improvements from back then. Therefore
the new mapnik-render-image starts with version 0.3.

Again, there were some changes and improvements, please check the CHANGELOG
file for details.

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

[OSM-dev] generate_image.py

[Stephan Bösch-Plepelits]

Hi!

I improved the script generate_image.py (which renders a map via Mapnik)
from OpenStreetMap SVN and published it on Github. Maybe you are
interested:
* https://github.com/plepe/generate_image.py

Use it, fork it, improve it, send pull requests :-)

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

[OSM-dev] pgmapcss 0.4.0 released!

[Stephan Bösch-Plepelits]

Hi!

The last month I spent on harmonizing pgmapcss with the MapCSS 0.2
specification. Finally the rendering order and most MapCSS parameters
follow this standard.

Also there were many bug fixes, most notably a re-implementation of the
eval()-parser which was really buggy.

When loading a MapCSS style you have to specify if you are using Mapnik 2.0
or Mapnik 2.2 - Mapnik 2.2 can read more properties from database columns,
therefore a smaller pre-processed Mapnik-file is possible (and more
properties may be the result of an eval()-statement).

I also updated the installation instructions, now it should be possible to
get to a rendered image in a couple of minutes :-)

There are a couple of things which are not possible yet (or need a lot of
work), notably coloured shield backgrounds and extrude-*. Also note that
pgmapcss depends on a osm2pgsql based database (with hstore column), which
usually does not contain all OSM data.

Get the source: https://github.com/plepe/pgmapcss/

Have fun! Please report issues on Github.

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

Re: [OSM-dev] visual timestamp from ways

[Stephan Knauss]

Could add that Bing is using a special Http header.  That's the way josm uses 
to display tile age. 



Toby Murray toby.mur...@gmail.com schrieb:
What's wrong with the /status URL on tiles? It works for osm.org and
Mapquest Open.
 I have from time-to-time problem that I don't know how old is a
particular
 tile service, even for my own ones I'm not sure if update is working
 properly or not. 


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

[OSM-dev] PGMapCSS 0.3.0

[Stephan Bösch-Plepelits]

Another two busy weeks and already version 0.3.0 is available, which
introduces a couple of very interesting features, noteably:

* Link Selectors are supported, with a syntax similar to JOSM, e.g.
  'rel[route=tram] [role=stop] node[railway=tram_stop]'

* There's a special link selector 'near' which matches objects in a certain
  distance. E.g.
  'area[landuse=cemetery] near[distance=0] node[historic=tomb]'
  selects all tombs inside a cemetery.

* Combine features: As streets in OSM are usually split into short parts
  (because of changing type, e.g. one ways, count of lanes, ...) labels are
  often missing or repeated too often. The statement 'combine' combines
  selected features into one.

There are some examples which illustrate these features:
https://github.com/plepe/pgmapcss/blob/master/examples/README.md

Here's the link to the library:
https://github.com/plepe/pgmapcss

Hope you like it :-) I'm interested in your feedback.

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

[OSM-dev] [Mapcss] Decision procedure for MapCSS (fwd)

[Stephan Bösch-Plepelits]

Hi!

I sent the attached email last week to the mapcss mailinglist.
Unfortunately I didn't get any answers, which is sad as I think that MapCSS
could need some development. Therefore I send this email to the osm-dev
mailinglist too, maybe there are some interested persons.

In the meantime I copied the MapCSS specification to a repository on Github
(which was fairly easy, as Github can render Mediawiki files):
https://github.com/plepe/mapcss

What do you think, anyone interested in improving MapCSS?

greetings,
Stephan

- Forwarded message from Stephan Bösch-Plepelits 
sk...@xover.htu.tuwien.ac.at -

Date: Fri, 23 Aug 2013 09:31:14 +0200
From: Stephan Bösch-Plepelits sk...@xover.htu.tuwien.ac.at
To: map...@openstreetmap.org
Subject: [Mapcss] Decision procedure for MapCSS

Hi!

As you might have read, I'm developer of a new MapCSS implementation,
PGMapCSS: https://github.com/plepe/pgmapcss/

I think that MapCSS has huge potential, as it is more general than other
definition languages like Cascadenik or CartoCSS. I've used Cascadenik long
enough to see its downsides (like complex database queries; no calculations).

My dream is that I can use the same map style on different devices: A web
site with a TMS/WMS based map; mobile devices with interactivity ; printed
maps; editors for OpenStreetMap data. Why not, if there are MapCSS
implementations for all these different devices.

On the other hand, MapCSS 0.2 is still very callow. Some definitions are
vague and important features are missing. The Wiki history shows, that
development has been very much in the hands of individuals. The conclusion
is the observable incompatibility between the different MapCSS
implementations.

I haven't found a procedure how new features are proposed, discussed and
finally decided. I also read the mailinglist thread from March 2013 with no
real outcome: 
http://lists.openstreetmap.org/pipermail/mapcss/2013-March/thread.html

I thought about proposing stuff on the Wiki Talk page, but as it is mostly
deserted since 2011 I don't have much hope for feedback. I also don't want
to change the specification myself - there should be some kind of decision
process, don't you think?

I don't want to whine. I think we need a strategy how to overcome this
solution. My proposal:

* We move the MapCSS specification to a GitHub repository, preferably
  openstreetmap/mapcss.
* If someone wants to propose a new feature, he/she creates a pull request,
  which will be merged by a maintainer after (say) a fortnight if no
  objections are raised.
* We can use the issue tracker to raise ideas and discuss details.
* We create a couple of reference styles for testing purposes, which are
  part of the repository.
* We finalize MapCSS 0.2 and allow only clarifications.
* We create a branch MapCSS 0.3 which will hopefully harmonize the
  incompatibilities.
* We document this decision process somewhere[tm].

There a several examples where specifications are developed on Github,
e.g.:
* https://github.com/mojombo/semver
* https://github.com/mustache/spec
* https://github.com/perl6/specs
Maybe we can take an example on them.

What do you think? I'd love to see MapCSS develop ...

greetings,
Stephan

PS: If we decide to move to Github, I offer to take care of the transition
process.

___
Mapcss mailing list
map...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/mapcss

- End forwarded message -

-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

[OSM-dev] Introducing PGMapCSS 0.2.0

[Stephan Bösch-Plepelits]

Hi!

PGMapCSS is a library for PostgreSQL/PostGIS which works between an
osm2pgsql based database and Mapnik. It processes database (usually
OpenStreetMap) objects according to MapCSS rules and calculates resulting
colors, widths and other properties for Symbolizers, even geometric
modifications.

Over the last couple of weeks PGMapCSS matured a lot since 0.1.0 -
thereofore it's time for a new release: 0.2.0. It's now a working library,
that displays MapCSS stylesheets with Mapnik. (Although there are still
some limitations: there are quite a few incompatibilities to pure MapCSS;
I hope to achieve more compatibility in the future.)

The biggest limitation in Mapnik is the lack of expression support for most
of the Symbolizer options (as I wrote in the first announcement). I solved
this by adding a pre-processor that generates Rules like:
Rule
  Filter[width] = '1' and [color] = '#ff'/Filter
  LineSymbolizer stroke-width='1' stroke='#ff' /
Rule
Rule
  Filter[width] = '2' and [color] = '#ff'/Filter
  LineSymbolizer stroke-width='2' stroke='#ff' /
Rule

This is not very efficient - but it works (as long as no eval()-statement
is used, because PGMapCSS can't guess the result of those and might miss a
combination).

Try it, tell me what you think of it:
* https://github.com/plepe/pgmapcss

Here are some examples:
* https://github.com/plepe/pgmapcss/tree/master/examples

On Sat, Aug 03, 2013 at 11:34:15AM +0200, Frederik Ramm wrote:
 AFAIK MapServer supports [using expressions for Symbolizer options].
 Tiling can then be done either via the standard MapServer toolchain, or
 MapProxy, or even continuing with mod_tile and using Tirex's mapserver
 backend.
I looked into the documentation of MapServer (and GeoServer), and I think
it won't work with PGMapCSS. I documented my findings in
https://github.com/plepe/pgmapcss/blob/master/doc/compatibility.creole

Maybe it would help if someone with more knowledge on MapServer (or
GeoServer or other software) would try it and report his/her experiences.

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

Re: [OSM-dev] Introducing PGMapCSS 0.2.0

[Stephan Bösch-Plepelits]

On Fri, Aug 23, 2013 at 11:52:02AM +0300, Jukka Rahkonen wrote:
 You can have several classes in a mapfile and classes can contain several
 styles. Layers, classes, and styles can all have scale denominators.
 Example showing many classes and styles per one database query
 http://latuviitta.org/tyylikirjasto/pg_roadsclose_10k_i.map
 This mapfile renders OSM highway layer.
Oh, that looks really good. After reading the documentation I thought that
you can have only one class per layer.

There's still a tiny bitt missing: I found that you can insert a !BOX![1]
in the database query as replacement pattern for the bounding box, but I
haven't found anything that you can do the same for the scale denominator.
PGMapCSS uses the current scale denominator for zoom level queries and unit
conversions.

Anyway, I will look into it and try to come up with a suiting MapServer map
file (maybe with a fixed scale denominator, so as the result is not zoom
level dependend). I guess that the scale denominator could easily be added
as replacement pattern to MapServer.

 Geoserver supports using SQL queries for selecting data nowadays
 http://docs.geoserver.org/stable/en/user/data/database/sqlview.html
 The name sqlview is misleading.
It's the same here, you can't insert BBOX and SCALE_DENOMINATOR in the
database query. This is the kind of database query that PGMapCSS likes to
use:
  select * from test_match(pgmapcss_render_context(BBOX, SCALE_DENOMINATOR));

where test_match is a function generated by PGMapCSS which queries all
features for the current zoom level from the database, and does all the
calculating for the resulting symbols. BBOX and SCALE_DENOMINATOR need to
be replaced by the renderer but their current values.

 Geoserver implements the SLD standard and filter capabilities can be read
 from http://portal.opengeospatial.org/files/?artifact_id=1188
PGMapCSS is not a pre-processor that generates an SLD stylefile from the
input style, but processes the input features itself and generates
parameters for symbolizers.

[1] http://mapserver.org/input/vector/postgis.html

Thanks for your input concerning MapServer!

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

[OSM-dev] Introducing PGMapCSS 0.1.0

[Stephan Bösch-Plepelits]

Hi!

I spent the last week hacking together a new project. It's an
implementation of MapCSS for Mapnik, called PGMapCSS. Yet another? No. In
contrast to other CSS implementations for Mapnik, PGMapCSS runs in the
database and evaluates the CSS rules for every object. This makes more
advanced checks and calculations possible; even geometric modifications
are possible (though not implemented yet).

Mapnik just needs to read those values and render them.

And this is currently the big limitation of this method: Mapnik can't use
expressions for most of it's Symbolizer options (not even colors or
rotation angles).
(This is something that already annoyed me when I first started to use
Mapnik in 2008 - see Mapnik issue #828).

So, PGMapCSS is currently only a technological experiment. Though for a
technological experiment it's already quite full-featured.

And here is the precious link to the source and documentation:
https://github.com/plepe/pgmapcss

What you need:
* PostgreSQL + PostGIS
* osm2pgsql
* Some way to render a mapnik file, e.g. mod_tile + renderd

Check out the source, play with it, fork it, contribute back. Tell me what
you think of it. There might still be a lot of bugs.

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

Re: [OSM-dev] Tile server

[Stephan Knauss]

On 20.06.2013 07:03, Kaur gill wrote:

I have /var/lib/mod_tile/default/0/0/0/0/0.meta.
But I don't know how to access it, through which file I should try to access it.


Usually you'll use the apache module mod_tile.
It will handle path requests like /1/1/0.png and serve the matching tile 
from the metatile you already have.


more details here and in the wiki, read mod_tile.
http://switch2osm.org/serving-tiles/manually-building-a-tile-server/

Stephan


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

Re: [OSM-dev] Label font scaling

[Stephan Knauss]

Lynn W. Deffenbaugh (Mr) writes:

Can you save me a bunch of research and just post an example of your  
entity declarations (not necessarily all of them) and one or two  
textsymbolizer instances that use them?


Maybe the scale_factor of mapnik2 can do the trick for you. My setup was  
originally done with 0.7 mapnik. I also wantet to increase everything by 1  
point. That can't be expressed by a single scale factor number.


Depending on which fonts you plan to use, be advised that with mapnik  
including the coming 2.2 there are unresolved issues with font rendering.  
You'll notice it when using multiline label or asian/indic characters.  
Solution would be to use the harfbuzz branch.


For my simple change I declared a set of new entities with straight-forward  
names to indicate what they usually represent:


!ENTITY size_8 9
!ENTITY size_9 10
!ENTITY size_10 11
!ENTITY size_11 12
!ENTITY size_12 13
!ENTITY size_13 14
!ENTITY size_14 15


In the rules declaration these entity names are used:
Rule
  Filter[amenity] = 'hospital'/Filter
  maxscale_zoom16;
  TextSymbolizer size=size_8; fill=#da0092 dy=10 fontset- 
name=book-fonts halo-radius=2 wrap-width=24  
placement=interior[name]/TextSymbolizer

/Rule


This gives you a single place to increase the font size. If nobody  
complains I can submit this.


Stephan

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

Re: [OSM-dev] Label font scaling

[Stephan Knauss]

I have increased the font size on thaimap.osm-tools.org as well. I did this by 
replacing the font sizes by xml entities and adjusting these. 

As it seems to be useful for others as well I could submit it to svn. 

If nobody disagrees I can submit it on Sunday. 

Stephan 



Lynn W. Deffenbaugh (Mr) ldeff...@homeside.to schrieb:

I'm running my own Tile Server (mod_tile/renderd created from packages 
as described at 
http://switch2osm.org/serving-tiles/building-a-tile-server-from-packages/
and 
would like to serve up a new set of tiles with larger font sizes for 
higher resolution displays.

I read 
https://help.openstreetmap.org/questions/8467/font-size-and-adding-scale-to-map

which describes the textsymbolizer element in osm.xml, to whit:

 https://help.openstreetmap.org/vote/8472/up/
 3
 https://help.openstreetmap.org/vote/8472/down/
  

 The font size comes from the style file /osm.xml/. This includes 
 several lines on the form /|textsymbolizer name=name 
 fontset_name=bold-fonts size=11/|/. You can edit the /size/ 
 parameter in the wanted areas to generate a new style with other font

 sizes.


But there's a TON of textsymbolizer's that would need to be edited. 
Cloudmade's tile servers support an embedded doubler in their tile URL 
as described at
http://developers.cloudmade.com/projects/tiles/documents

 To get double resolution tiles use *@2x* suffix: 997@2x - this will 
 improve map look for iPhone 4, Motorola Milestone, etc.

Does anyone know how they do that?  Is there a way to replace the 
textsymbolizer element size attributes with a variable (say Size11, 
Size8, SizeN) so that I can simply clone the style and edit all of the 
sizes in a single place?  Then I could do a 1.5, 2, 4, or whatever by 
simply editing the sizes where the variables are declared instead of 
every single textsymbolizer element.

Any/all help would be appreciated to accomplish label font scaling in 
the rendering chain with minimal manual editing work for each scale
that 
I support.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32





___
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] Reminder: Node 32-bit exhaustion

[Stephan Knauss]

On 08.02.2013 06:59, Ilya Zverev wrote:

Though I fail to understand what would be broken if you continue to use
32-bit osm2pgsql. Indices, maybe.


don't be confused by the term 32-bit. It is required that the software 
can handle 64-bit data types for processing the node id. In postgresql 
it will be stored in a column declared as BIGINT.


Data types often are signed. So one of the 32 bits is used to store the 
sign. The remaining 31 bits to store the ID are exhausted now.


Software can be compiled as a 32-bit or 64-bit executable. If you can, 
you should use a 64-bit executable as this can access over 4GB of 
memory, giving you the chance to speed up the import a lot.



What happens when you continue to use osm2pgsql with 32 bit ids (int4) 
instead of int8?


Have a look at osmtypes.h. You'll see that osmid_t is declared as 
int32_t which is signed:

typedef signed long int int32_t

So the value will overflow. In the best case osm2pgsql will abort with 
an error. In the worst case your database content will be corrupted. 
Your database structure still is only int4, again signed. So it all 
needs to be converted into int8.


Probably easiest is to re-import into a fresh DB with 64-bit IDs. Most 
people have done this step during the re-import after license change.


Stephan



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

Re: [OSM-dev] Reminder: Node 32-bit exhaustion

[Stephan Knauss]

On 06.02.2013 21:25, Andrew M. Bishop wrote:

Does anybody know if there is a released version of Mapnik that
supports ids up to (2^32)-1 rather than requiring an unreleased 64-bit
version?


could you give details about a use case where mapnik needs the osm_id? 
The official styles do not contain a reference to osm_id, it's an 
internal thing in the database.


Or is it going into using osm directly as a datasource instead of postrgres?

Might be worth being clarified on the wiki page. Currently it reads as 
mapnik is broken in general.


Stephan


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

Re: [OSM-dev] Reminder: Node 32-bit exhaustion

[Stephan Knauss]

Hello Andrew,

On 05.02.2013 21:13, Andrew M. Bishop wrote:

Since 2^31 nodes will make older versions of some software unusable
and 2^32 nodes will make other versions unusable it would be helpful
to have a wiki page to record this information.  I think that most
useful would be a table of the minimum version of each piece of
software to support true 32-bit ( 2^31) and 64-bit node numbers.


I was going to suggest exactly the same.

I recently double checked and contrary to my believe, my server was not 
a 64bit installation but 32bit userland inside a 64bit kernel.
Maybe I selected the wrong basic image when buying the vserver years 
ago. And PHP has only 64bit ints as a 64bit binary :(


I verified my scripts and think they are safe. You might want to check 
yours as well.


I hope most software should be able to handle a long long (64bit int) on 
a 32 bit platform, checking does help bringing clarity.


Sharing some basic stuff for an upcoming wiki page:

How do I find out how many bits my server OS has?

Windows:
wmic os get osarchitecture

Linux
kernel:
uname -m

software:
dpkg --print-architecture


Webspace with PHP:
?php
echo PHP int size: .PHP_INT_SIZE. which is max .PHP_INT_MAX;


Consequences of 32 bit:
PHP doing postgresql queries return ID from bigint column not as 
integer, but as string. If doing numerical operations a lib like GMP is 
required.



Stephan


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

Re: [OSM-dev] Reminder: Node 32-bit exhaustion

[Stephan Knauss]

On 06.02.2013 00:17, Steve Bennett wrote:

I might be pointing out the obvious here, but isn't the bigger risk
that some software will fail silently rather than catastrophically?
Like, an editor tries to save node 2^32+100, and saves it as 100, or
something?


It is, but API requires you to provide a version along with PUT. So 
hopefully it would trigger a conflict in some cases.


Stephan


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

Re: [OSM-dev] area filtering on change streams?

[Stephan Knauss]

On 18.01.2013 18:53, Brian Cavagnolo wrote:

I'd like to maintain an updatable database of OSM data clipped by a
polygon.  I understand how to initialize the database using osmosis'
--bounding-polygon task.  But this task does not seem to operate on a
change stream.  Any recommendations on trimming a change set down?


As you already noticed only nodes have a coordinate and can be used for 
filtering.
Select your bounds a bit bigger and filter later in the database. I'm 
using a cron job to clean it up.


http://wiki.openstreetmap.org/wiki/User:Stephankn/knowledgebase#Cleanup_of_ways_outside_the_bounding_box


Stephan


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

Re: [OSM-dev] Planet.osm delayed

[Stephan Knauss]

May I wish for line feeds similar to the regular planet also in the full 
history one? Would make processing with standard tools like grep possible. 

Size should not be the problem. I expect it to compress similar well.  And for 
compact storage there is pbf as well. 

Stephan 


Paweł Paprota ppa...@fastmail.fm wrote:

Hi Grant,

On a not-so-unrelated note - when is the next full history dump
planned?

Paweł


___
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] Timestamp in PBF files

[Stephan Knauss]

Frederik Ramm writes: 

I really don't mind *how* it's done but I would really love to have one 
agreed way to place a timestamp in a PBF instead of everyone rolling their 
own.


I would prefer epoch timestamps. That's a widely accepted way of storing 
time information without the need to worry about time zones and such. 

While we change the header: Could we also include a field to indicate a 
full history planet? After the redaction period the lat/lon is only a 
required field for non-redacted elements.
Is it possible to express this in protobuf? 

If not, it would be fine to have at least a defined value for undefined 
we could document. If I remember correctly Jochen suggested to use MAXINT 
for this. 


Stephan

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

Re: [OSM-dev] Timestamp in PBF files

[Stephan Knauss]

On 20.11.2012 20:28, mar...@gmx.eu wrote:

Stephan, what did you mean we would need this undefined for?

I should not have mixed topics.

In case you process a full history pbf then it happens that nodes which 
were redacted are stored with MAXINT for lat/lon. This is because 
lat/lon are required fields. Jochen mentioned this a few mails back.


A software reading history PBF might want to handle these elements in a 
special way...


Stephan



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

Re: [osmosis-dev] Invalid actions during replication

[Stephan Knauss]

On 11.11.2012 11:24, Paweł Paprota wrote:

By invalid action I mean a situation when there is a delete action
in the pipeline but there is no entity in the database to delete. Or
modify action with version X when there is no version X - 1 in the
database but some other version.


Do you have --simplify-change or --sort-change in your pipeline? I have 
not fully thought about it, but it might introduce funny effects if you 
rely on a special order of actions.


Stephan



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

Re: [OSM-dev] 404 from Apache2/mod_tile

[Stephan Knauss]

On 09.11.2012 20:37, Stefan Elspaß wrote:

This is indeed the case, but sometimes - in these seldom cases when
rendering on the first request works - the command RenderPrio instead
of command Dirty appears in /var/log/syslog (see below). Does that
indicate that it might by a load-related decision from mod_tile?



mod_tile does read system load:
get_load_avg()

If this is higher than config value ModTileMaxLoadMissing then 404 is 
returned.


But you should see this in the logfile. Can you enable level info?
ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, Load larger 
max_load_missing (%d). Return HTTP_NOT_FOUND., scfg-max_load_missing);


Stephan



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

Re: [OSM-dev] ODbL full history planet

[Stephan Knauss]

Hello Jochen,

thank you for this explanation. Explains what I'm seeing with an osh.pbf

On 30.10.2012 10:46, Jochen Topf wrote:

PBF files don't have a way of storing non-existing coordinates. When PBF was
invented this couldn't happen and nobody ever thought of adding it.


could specifying MAXINT as the value for non-exisiting lat/lon values in 
a full history pbf be a solution?


I still have no stock tooling for reading either the xml file and grep 
for a node nor pbf tools to inspect how the version history of a 
redacted node looks like.

So unfortunately can't simply try to see what's happening.


Osmium uses MAXINT (boost::integer_traitsint32_t::const_max) to mark invalid
positions internally. This will show up as 214.7483647 externally if whatever
code you have doesn't check the result of the defined() method.


I used your osmium_convert example to convert the osh.xml into osh.pbf. 
As you said, it does not include any checks for defined(), so it all 
ends up in PBF.


I did not see anything special about lat. Both fields would be MAXINT, 
right?

Maybe it's limited in osmconvert. Can't follow that code :(


O:\osmconvert.exe --out-statistics history_2012-10-13_13_35.osh.pbf
timestamp min: 2005-04-18T14:12:45Z
timestamp max: 2012-10-13T11:35:31Z
lon min: -,.),(-*,(
lon max: 214.7483647
lat min: -90.000
lat max: 90.000
nodes: 2325354854
ways: 273053641
relations: 6210920
node id min: 1
node id max: 1962486877
way id min: 35
way id max: 185598826
relation id min: 2
relation id max: 2474614
keyval pairs max: 7838
keyval pairs max object: way 17441262
noderefs max: 49189
noderefs max object: way 29310085
relrefs max: 69643
relrefs max object: relation 82682


Stephan


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

Re: [OSM-dev] ODbL full history planet

[Stephan Knauss]

Pascal Neis writes: 


Jochen Topf schrieb:
 What about redacted versions of nodes without coordinates?
can you please give an example Node ID for that?
I mean, did the bot really only removed lat/lon of
a node and not the entire version no. of a node?


for example here:
http://www.openstreetmap.org/api/0.6/node/573785524/history 

entry does not contain lat/lon, also versions are missing. 


Was also discussed in this thread:
http://lists.openstreetmap.org/pipermail/rebuild/2012-July/000299.html 

Can the software/osmium cope with that? what will end up in the pbf file? 


Stephan

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

Re: [OSM-dev] ODbL full history planet

[Stephan Knauss]

On 19.10.2012 16:53, Matt Amos wrote:

now available from:
http://planet.openstreetmap.org/planet/full-history/
only limited testing has been done on this file (checking for XML
well-formed-ness and various spot-checks on elements), so please let me
know if you find any errors with it.


I have not yet downloaded it, hoping Peter will make the pbf conversion 
available which is a lot faster to process and saving my time to do the 
conversion by myself.


Can you give a rough outline on how the content changed compared to the 
pre-redaction full history planet?


In what way will be redacted entries presented? I expect the 
representation to be similar to the /history API call. Is that true? any 
other gotchas?


Stephan


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

Re: [OSM-dev] missing nodes

[Stephan Knauss]

Hi David, 

David Prime writes: 


wrote my own filter tool which gave the same results. Looks like it's just
how it is, but I'm wondering what the point of a way with broken noderefs
is. Is it corruption or a feature?


There shouldn't be that many missings refs at all. 

What is the source of your England dump? Is it contained there? I read your 
sentence below that it is already missing in your input file. 


 to get chopped off at borders and so on but I've done it manually via a
 java program that parses the full england dump and I've counted
 ~1.3million
 ways which reference nodes that I could not find in the same XML file.



Stephan

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

Re: [OSM-dev] osm2pgsql and bbox imports

[Stephan Knauss]

On 12.10.2012 18:38, Peter Wendorff wrote:

Am 12.10.2012 18:12, schrieb Stephan Knauss:

Peter Wendorff writes:

osm2pgsql has to store nodes outside the bbox because geometries that
overlap the borders etc. should be included in the result, too.

how certain are you regarding this?

It's only based on my observations and short comments on questions
regarding that in the IRC channels.
My germany extract import took incredibly long and the number of nodes
in the slim nodes table is around in line with the data stats for
Germany as a whole, while I only imported one city (by bounding box
filtering).


I can say it's a bug with pbf processing. I was able to reproduce the 
problem and created a ticket.


https://trac.openstreetmap.org/ticket/4625


I suggest you have a look at the filtering capabilities of osmconvert. 
It was able to extract my desired bbox out of the 2GB asia extract 
within 5 minutes.


The resulting database is now 40 times smaller and in a range I was used 
to before my software upgrade.


Stephan


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

Re: [OSM-dev] Improved text rendering in Mapnik

[Stephan Plepelits]

On Sat, Oct 13, 2012 at 03:44:01AM +0200, Hermann Kraus wrote:
 As my Google Summer of Code project I worked on improving Mapnik's text  
 rendering. The most important change was adding support for complex  
 scripts, but I also implemented some other nice features. You can read  
 more about my work here:
 http://mapnik.org/news/2012/10/06/gsoc2012-status9/
 Build instructions are included and I would like to hear about your  
 success stories, but bug reports are also welcome.
Wow, thanks a lot! I was especially waiting for the upright=
functionality.

In an application I'm planning to use this, I would actually prefer to use
an alternate text if it is turned upside down (because I'd like to print
- that way or that way - depending on rotation).

Something like:
TextSymbolizer upright=alternate 
alternate_text=[name_right][name_left]/TextSymbolizer

or (maybe easier):
TextSymbolizer upright=only_left[name_left]/TextSymbolizer
TextSymbolizer upright=only_right[name_right]/TextSymbolizer

Do you think this would be possible?

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Plepelits,  |
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'


signature.asc
Description: Digital signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] OSM Wishlist

[Stephan Knauss]

On 12.10.2012 01:58, Tom MacWright wrote:

What do you want to see happen with OSM's software this year? What are
the tasks which everyone agrees on, but nobody has had the time to tackle?
There are some ideas around but I'm still missing a tool that can 
graphically show the diffs on an area/changelist.


Let's start with geometry modifications.

Typical situation: I look at the map in my area and I could bet there 
was a road at a specific point. Now I want to know: Was there a road in 
the past?


I want to open my history-browser, select the area of interest and then 
tick a check-box to view all deleted nodes,roads (within a defined 
timeframe, maybe a slider).


If I identify a changeset which did delete that way I want to know what 
else that changeset did.
So I want to have it display the state of the map before the edit and 
the geometry changes of that changeset in a different colorset.


To make it even more convenient intelligent filters can remove changes 
from the display where for example a node was deleted but in the same 
position is an area which has the tags as well. This should filter 
conversion of POI nodes into POI areas.


Deleted roads could be filtered if the road network contains a new road 
connecting the end-nodes so no gap was created. This is a more complex 
filter as it could be multiple edits involved.


So I want a tool that makes it possible to do a quality control by 
checking diffs like it's possible in wikipedia for years. The problem is 
that our data is a lot harder to diff.



Stephan


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

[OSM-dev] osm2pgsql and bbox imports

[Stephan Knauss]

Hi,

I'm doing a slim mode bbox import for rendering.

What is supposed to be in the planet_osm_nodes table? All nodes of my 
import source file or only the nodes contained in the bbox?


I used this bbox:
--bbox  97.3,5.6,109.6,23.4

and planet_osm_nodes contains for example this:

id;lat;lon
1744503310;1003244360;-1936959139;

Is it supposed to be there?
If so, it would be a lot faster to preprocess the input file with bbox 
clipping before feeding it into osm2pgsql.


Was this changed recently? I have the impression that in the past it did 
not contain these nodes.


Stephan

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

Re: [OSM-dev] osm2pgsql and bbox imports

[Stephan Knauss]

Peter Wendorff writes: 

osm2pgsql has to store nodes outside the bbox because geometries that 
overlap the borders etc. should be included in the result, too.

depends on the cutting algorithm used.
I could live with osm2pgsql doing a hard cut as I made my bbox large enough 
to have some buffer. If reference completeness is a requirement it's still 
possible to pass it to a softcut filter before and leave away the bbox at 
all.

Here is a description of two implemenations of a cutting algorithm
https://github.com/MaZderMind/osm-history-splitter 



Yes, preprocessing might be faster therefore, but that might depend on 
your system setup and where the bottleneck of your pipeline is, as the 
cutting process faces the same problem here: it runs several times over 
the input file to find dependent nodes for ways that are partly in the 
extracted target area.


My problem is that a database which was always around 2GB grow to 40GB 
during the import process and this is killing my vserver. It simply can't 
cope with the I/O load. I used the asia extract as my input file as I did 
before but now the nodes table contains data 90 degrees away from my 
bounding box. 

My setup documentation does not mention anything that I manually cleaned up 
the nodes table after import. So it could have been a change in osm2pgsql 
as well. 


Stephan

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

Re: [OSM-dev] osm2pgsql and bbox imports

[Stephan Knauss]

Peter Wendorff writes: 

osm2pgsql has to store nodes outside the bbox because geometries that 
overlap the borders etc. should be included in the result, too.


how certain are you regarding this? 

in parse-primitive.c::EndElement() I see a call to node_wanted() which only 
returns true if the coordinates of the node are inside the bounding box. 


it later calls osmdata-out-node_add
in output-pgsqlo.c this is pgsql_add_node which calls pgsql_nodes_set.
This is calling a prepared statement which inserts the node in the 
planet_osm_nodes table. 



My question is: is this code path also used during initial import?
Is this code path used during incremental updates? 



My previous imports had used the xml extract as the debian protobuf library 
did not work as expected. I have now also updated protobuf and using now 
pbf as an input file. 

The code in parse-pbf::processOsmDataNodes() does not call node_wanted(). 


Could it be it's simply missing there?
after this line
lon = lon_offset + (node-lon * granularity);
doing the node_wanted call and only then process the node? 



Stephan

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

Re: [OSM-dev] OSM Wishlist

[Stephan Knauss]

Serge Wroclawski writes: 


This is expensive.
does this matter? Is there a requirement to have it running against the 
latest r/w api? 

I fetch my osm data for editing from the osm ro-mirror (overpass). This is 
a lot faster than waiting for main API. Works fine as well.
Why not add another (or a 3rd, 4th, ...) ro-mirror for these special tasks. 
load can be distributed quite easy onto different servers.
Could even be a database made specifically for these history calls. Just 
preprocess the geometry. 

And if it must be working with the latest revision because the data is 
newer than a few minutes then the API could query this service and in case 
it's not available there only then doing the expensive calls. 

I once thought of implementing something like this. I think Peter already 
has a prototype doing similar.
https://github.com/MaZderMind/OpenStreetMap-History-API 


Stephan

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

Re: [OSM-dev] OSM Wishlist

[Stephan Knauss]

On 12.10.2012 01:58, Tom MacWright wrote:

What do you want to see happen with OSM's software this year? What are
the tasks which everyone agrees on, but nobody has had the time to tackle?
reading some of the answers it also seems that appropriate server 
hardware is an issue for many of the smaller projects.


We have developers with great ideas but often the hardware is not 
powerful enough to provide their services world-wide.


If the funding limited to software development? Or could it also be used 
to provide a technical infrastructure for the various projects that are 
already around?


Bringing a prototype project to a server also has different problems. 
Clear technical documentation can help to deploy a service better or use 
the existing tools more efficient.


Writing good technical documentation is a rare skill, having support in 
this area can help boosting our existing developer activities and bring 
up new great projects.


Stephan


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

Re: [OSM-dev] how to debug rendering issue

[Stephan Knauss]

On 11.10.2012 01:30, Martin Guttesen wrote:

yep checked the db and the buildings are there

the strange thing is that this problem is only in this area, if you go
east to the next village, there all the buildings and house numbers show


Interesting would be if there was any problem with querying it from the 
db. Did you check postgresql log already?


I was close to enabling postgres logging to see all the single queries. 
You might try that and check the query calling for the buildings. You 
should see this query in the mapnik style file and recognize this 
pattern in the postgres queries.


You'll need multiple settings to enable logging.
http://stackoverflow.com/questions/71/how-to-log-postgres-sql-queries

Are you running any modifications besides only processing an extract? 
What version of postgres/postgis/mapnik is in use?


Stephan


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

[OSM-dev] how to debug rendering issue

[Stephan Knauss]

Hi,

I have a strange rendering issue on my server.

This highway is not rendered:
http://www.openstreetmap.org/browse/way/177905977

The other oneway highway next to it is rendered:
http://tile.osm-tools.org/osm_then/18/203537/124374.png

On osm.org both ways are rendered:
http://tile.openstreetmap.org/18/203537/124374.png


I checked the database and the way is included in planet_osm_line (as 
well as in _roads)


select * from planet_osm_line where osm_id=177905977
177905977;;secondary;;yes;;;401;;paved;;;6;;ref=401, 
oneway=yes, highway=secondary, surface=paved, 
dual_carriage=yes;01022031BF0D006A0048E17AEC461A65413D0AD7A376362F41CD54491A6541AE47E17A76362F41E17A140E711A6541713D0AD781362F410088D31A6541F6285C0FBC352F41D7A37025081B6541FE342F41C3F528C4171B6541A4703D0AF9342F41D7A370F5921B65411F85EB5120362F4114AE4739A21B6541C3F5285C7B362F415C8FC28DAD1B65415C8FC2752C372F41AE47E18AB31B654148E17A946B382F4185EB5128BF1B654114AE47619F3B2F415C8FC275C51B6541A4703D8A283C2F4114AE4779D21B6541A4703D8A8B3C2F418FC2F578E91B6541B81E85EBCF3C2F41F6285C97181C65413D0AD7231B3D2F419A99521C65417B14AEC7DC3D2F4152B81EF56B1C6541713D0AD7D53D2F4152B81EF5851C654114AE4761EC3D2F418FC2F5E8BE1C654152B81E05603E2F41EC51B82E1B1D65410AD7A3F0AA3E2F4148E17AD44D1D654185EB51B8C53E2F41E17A145E651D65411F85EBD1413F2F413363B91D65419A99A3412F41A4703DDAD91D6541A4703D8A36422F4166C62E1E654185EB51B87D432F417B14AE27781E6541E17A14AE19442F41F6285C078D1E654114442F411F85EB79321F65418FC2F528C8422F417B14AE87EF206541D7A3703D7D3F2F4148E17AF43B21654152

B81E85EC3E2F41E17A14DE56216541A4703D8AB93E2F4185EB511097216541295C8FC2413E2F4148E17AECFB216541A4703D8A853D2F411F85EB6192236541D7A3703DDE372F41F6285CCFD12365411F85EBD19E372F41295C8F5A4F246541C3F5285C4F382F4100886F256541713D0AD70F3A2F41E17A14BE922565417B14AEC7183A2F4152B81E5DC8256541C3F5285CB6392F419A414027654152B81E05A1352F4152B81E453F296541AE47E1FAE7312F4114AE47495829654185EB51B880312F419AA97C29654152B81E0575302F41EC51B89EDC296541A4703D8A172D2F410AD7A3E0FB2965419A192B2B2F4148E17AFC172A6541F6285C8F22292F411F85EBA1762A6541295C8F428E222F41EC51B83E8E2A6541B81E85EB1D212F4152B81EF5A82A6541D7A3703D38202F41295C8F92D92A65411F85EB510D1F2F41E17A1486F62A6541E17A142EC71D2F41A4703D7A3E2B654166E6211A2F41AE47E14AB52B654133B323142F4148E17A84F22B6541F6285C8F30112F413D0AD76B0A2C654114AE47E1A0102F415C8FC2DD242C654152B81E0576102F419AC1642C6541713D0AD770112F411F85EB29072D65413D0AD7A3E0132F4114AE4711262D65415C8FC2F5F3132F4166AE592D65413D0AD723C2132F41D7A37025F42D6541A4703D0A
EC122F413D0AD793122E6541E17A14AEBD122F41EC51B86E222E65411F85EBD155122F41A4703D02552E65417B14AEC7580F2F41B81E854B762E65415C8FC275660D2F413D0AD7B3972E6541AE47E17A120C2F41CDA4B52E654100806C0B2F41B81E85BBFB2E654148E17A14930A2F41713D0AB75B2F6541E17A14AE50092F413D0AD72BBE2F65410AD7A3F00D092F41333B04306541713D0AD7E9082F41713D0A5F18306541EC51B89E54092F41B81E85032B306541C3F528DC480A2F41663E3C306541F6285C8F880B2F415230654133B38C0C2F41AE47E1CA66306541B81E85EBFD0D2F419AB17C3065419A19AF0E2F413D0AD703A2306541AE47E1FA240F2F4100E8C1306541295C8F42510F2F41E17A142EF4306541EC51B81E3E0F2F4114AE47210C31654114AE47E1380F2F4166E60E3165417B14AE47380F2F419A99173165411F85EBD1F90E2F41F6285C77343165418FC2F5285C0E2F41C3F528EC49316541295C8F42B20D2F4166AE6131654152B81E85AB0C2F417B14AE077831654148E17A94910B2F419AC9993165410AD7A370EA092F416686AB316541713D0A570E092F4100E0BF3165415C8FC2F5E8072F41AE47E112CD316541D7A3703D0B072F416646DE3165417B14AEC7A3052F
413D0AD7EBE6316541F6285C0FB5042F418FC2F5B0ED316541CD4C0B042F41A4703DCAF7316541EC51B81E83022F4152B81EF505326541D7A3703D7F002F41295C8F02173265415C8FC2F503FE2E41295C8F721F326541E17A142EB7FC2E4148E17A9435326541EC51B81E8DF92E411F85EB094C32654166E636F62E41295C8FE25932654133B335F42E41AE47E1BA73326541A4703D8A90F02E419A0974326541A4703D0A81F02E41295C8FC27632654148E17A14F8EF2E411F85EB6984326541F8ED2E417B14AEB79D32654100804DEA2E41

In the log files I see nothing unusual. My rendering is done using 
tirex. Setting debug=1 in mapnik.conf only returns this in the log which 
sounds ok:
sending: 
id=1349812110_147016472#012map=osmthen#012metatile=/var/lib/tirex/tiles/osmthen/18/49/30/181/29/0.meta#012render_time=598#012result=ok#012type=metatile_render_request#012x=203536#012y=124368#012z=18



Data is imported using 64 bit ID mode osm2pgsql. Postgresql is 9.2.1 
with postgis 2.0.1. Mapnik is 2.1.0. Tirex and the osm mapnik style are 
both up to rev 28793. Style was only modified for a different font, but 
as both highways in the given tile are a secondary, I see no reason why 
only one should render.



What possibilities do I have for debugging into this issue? Can I enable 
more verbosity? What could cause a symptom like this?




Stephan

___
dev mailing list
dev@openstreetmap.org
http

Re: [OSM-dev] node/way/relation IDs

[Stephan Knauss]

Bernhard R. Fischer writes: 

Do nodes, ways, and relations share a common pool of IDs (i.e. there is no 
node which has the same ID as a way), or do those object have separate ID 
pools (i.e. there may be a node which has the same ID as a way)?


No, their ID is independent, ID numbers carry no relationship between 
elements: 

http://wiki.openstreetmap.org/wiki/Elements#Common_attributes 


Stephan

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

Re: [OSM-dev] Osmosis exception

[Stephan Knauss]

Stéphane Henriod writes: 


This error message talks about a config file $WORKDIR_OSM/configuration.txt
but I don't have any at this location... Should I create it myself? And
what should it contain?


have osmosis create it and edit it to match your state.txt. 


See the wiki:
http://wiki.openstreetmap.org/wiki/Osmosis/DetailedUsage#--read-replication-
interval-init_.28--rrii.29 


Stephan

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

Re: [OSM-dev] Osmosis exception

[Stephan Knauss]

Stéphane Henriod writes: 


Just one thing I am not sure about: should the state file be downloaded
before we download each diff file? Or only once, before the first diff
download?


you only need to initialize once. Osmosis will update the state.txt to 
reflect the current state of replication. 

So with subsequent calls osmosis knows where to continue. 


Stephan

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

Re: [OSM-dev] determining the boundaries of cities?

[Stephan Plepelits]

Hi!

 I don't think we have something like that, as - see above - the big  
 question here remains: what is an urban area and what is a rural one?
I think there is no such thing in OSM yet (and I doubt there ever will be).
But to help think about it, here's a definition of the national Austrian
statistical agency:

Statistics Austria provides maps with urban areas for Austria. Their
definition, either:
- a built-up area with cleary visible road classification
- a group of houses sharing a place name
- a group of houses where the distance between each house is less than 200m
(Statistics Austria 2010, p. 1023).

It gets more complicated: Only houses will be counted, where:
- at least one people has a principal or secondary residence
- and at least four neigbours in 200m distance
- no objects with agriculture use
- also all objects which are registered as workplaces
(Statistics Austria 2010, p. 1025)

Finally the name of the largest place in the urban area will be used (or
several names if places with equal importance are found), prefixed by SE
(Siedlungseinheit = Settlement Unit).
E.g.:
SE Vienna (SE Wien) is much larger than the actual administrative borders 
(see Statistics Austria 2010, p. 1026).
SE Dornbirn, Feldkirch is the urban area with the main places Dornbirn and 
Feldkirch
(Statistics Austria 2010, p. 1025f)

More Information (sorry, only German):
http://www.statistik.at/web_de/klassifikationen/regionale_gliederungen/siedlungseinheiten/index.html
 (rough Shapefiles are available there)
Map:
http://www.statistik.at/web_de/static/siedlungseinheiten_nach_groessenklassen_gebietsstand_1.1.2010_041267.pdf

Literature:
Statistics Austria 2010, Neuabgrenzung der Siedlungseinheiten 2010,
http://www.statistik.at/web_de/static/neuabgrenzung_der_siedlungseinheiten_2010_058184.pdf

greetings,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Plepelits,  |
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'


signature.asc
Description: Digital signature
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Point osmand to own tile Server

[Stephan Knauss]

On 23.04.2012 23:28, qunuxy wrote:

Anwar Azulfa wrote

where the code which i should change on osmand ?

Look at getMapnikSource():
http://code.google.com/p/osmand/source/browse/DataExtractionOSM/src/net/osmand/map/TileSourceManager.java


No. This is the config file, which is requested by the application:
https://code.google.com/p/osmand/source/browse/config/site/tile_sources.xml

Stephan

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

Re: [OSM-dev] how to delete oauth_clients application ?

[Stephan Knauss]

On 23.04.2012 19:03, Cyrille Giquello wrote:

2012/4/23 Tom Hughest...@compton.nu:

I suspect a DELETE on:
  http://www.openstreetmap.org/user/UserName/oauth_clients/id
will work, but I haven't tried it.

I did:
http://www.openstreetmap.org/user/UserName/oauth_clients/xxx/delete


Tom suggested to try a http DELETE. What you did looks like a GET to a 
completely different URI.

Have you tried the way Tom suggested?

Stephan

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

Re: [OSM-dev] tirex-batch tiles are not used by mod_tile

[Stephan Knauss]

Max Wukits writes: 


this took about 5days of rendering time, but it seems, that this tiles are not 
used by mod_tile. here are some lines from tirex/jobs.log
I'm not sure about your log output. Is it possible that your tiles are 
considered outdated?
Can you compare the timestamps with planet-import-complete? 


Stephan

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

Re: [OSM-dev] replicate-sequences tool bust?

[Stephan Knauss]

On 03.03.2012 03:32, Lynn W. Deffenbaugh (Mr) wrote:

I tried the contact the tool owner link (maz...@toolserver.org), but
my e-mail bounced.
Is this the place to report this issue or is there a better place?


I have an alternative Mail contact of Peter and forwarded the problem 
description.


I also think he is active on this list. Guess he will answer soon...

Stephan

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

Re: [OSM-dev] 120111 Planet Node Order?

[Stephan Knauss]

Hi Simon,

On 15.01.2012 11:09, Simon Poole wrote:

To give you current numbers, I just did (10 days ago) an import on a i7
2600, 16GB box that took 30 hours with the initial import phase running at

Can you add your specs to the benchmarks page?

http://wiki.openstreetmap.org/wiki/Osm2pgsql/benchmarks

Your machine look similar to the Hetzner EX4 listed there but your 
import was seven times faster.


Stephan

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

[OSM-dev] oAuth PUT not working

[Stephan Knauss]

Hi,

I had a working PHP script to edit tags. It uses the pecl oauth library.

Now it stopped working. I suppose it is broken since the last changes on 
the OSM servers end of November. The script is rarely used so I just 
noticed the problem.


My token is valid.

It is possible to issue a GET request to read the preferences.
But it fails with a result 401 when trying to issue a PUT request for 
creating a changeset.


Is there anything I need to update on my side to make it work again or 
is the server side broken? Wiki mentions I have to use version 1.0 which 
the script seams to do.

http://wiki.openstreetmap.org/wiki/Oauth

I replaced some data by XXX:

This is working:
http://api.openstreetmap.org/api/0.6/user/preferences?oauth_consumer_key=XXXoauth_signature_method=HMAC-SHA1oauth_nonce=19951763504f130b4716dd67.25809464oauth_timestamp=1326648135oauth_version=1.0oauth_token=XXXoauth_signature=XXX

This fails:
[headers_sent] =
PUT /api/0.6/changeset/create HTTP/1.1
User-Agent: PECL-OAuth/1.2.2
Host: api.openstreetmap.org
Accept: */*
Authorization: OAuth 
oauth_consumer_key=XXX,oauth_signature_method=HMAC-SHA1,oauth_nonce=20733262254f130b476499b0.46798374,oauth_timestamp=1326648135,oauth_version=1.0,oauth_token=XXX,oauth_signature=XXX

Content-Length: 161
Content-Type: application/x-www-form-urlencoded

[headers_recv] =
HTTP/1.1 401 Authorization Required
Date: Sun, 15 Jan 2012 17:22:15 GMT
Server: Apache/2.2.14 (Ubuntu)
X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.11
WWW-Authenticate: Basic realm=Web Password
X-UA-Compatible: IE=Edge,chrome=1
X-Runtime: 1.003074
Cache-Control: no-cache
Status: 401
Vary: Accept-Encoding
Content-Length: 25
Content-Type: text/html; charset=utf-8


Stephan


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

Re: [OSM-dev] oAuth PUT not working

[Stephan Knauss]

Hi,

for the archive...

On 15.01.2012 18:39, Stephan Knauss wrote:
I sniffed JOSM communication to spot any difference in the oauth setup. 
To my surprise there was no difference, still my requests failed with 401.


So I compared other headers as well. It happened that I did not declare 
any content type, so it ended up as application/x-www-form-urlencoded



This fails:
PUT /api/0.6/changeset/create HTTP/1.1
Content-Type: application/x-www-form-urlencoded
[headers_recv] =
HTTP/1.1 401 Authorization Required


As the data is actually xml I changed it to Content-Type: text/xml
And surprise: The server now accepts my edits again.

But why did it respond with 401 Authorization Required? I guess there 
are other http status codes more appropriate. Why not 400 Bad Request?


Stephan


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

Re: [OSM-dev] oAuth PUT not working

[Stephan Knauss]

Hello Tom,

thank you for looking into this issue.

On 15.01.2012 20:42, Tom Hughes wrote:

On 15/01/12 19:26, Stephan Knauss wrote:

But why did it respond with 401 Authorization Required? I guess there
are other http status codes more appropriate. Why not 400 Bad Request?

Were you perhaps using an XML content type when computing the signature?
That would lead to a signature mismatch if you then sent a different
content type to the server.


The signature is computed inside the oauth library. It does all the 
magic internally. I just pass my data in. the $changesetRequest contains 
the XML of the changeset to create.


It worked in the past. Now I added the Content-Type header. I can't tell 
what it is using internally to compute the signature. I saw the 
content-type in the header and changed into text/xml as this was working 
for JOSM and sounds a lot better than what was sent before.


$ret = $oauth-fetch($api_url/changeset/create, $changesetRequest, 
OAUTH_HTTP_METHOD_PUT, array('Content-Type'='text/xml'));


Could it happen that the signature verification on the server is now 
more strict so a thing that worked in the past is now failing?



Stephan

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

[josm-dev] How to report EDT violations

[Stephan Knauss]

Hi,

a while ago JOSM started to print EDT violations in the console window.

As these are quite frequent I thought they would be fixed fast. However, 
they seam to persist. For example when opening the history dialog it 
floods the console for some seconds before the dialog opens.


What would be the preferred way to report these? Create a trac ticket 
for each callstack that looks unique?


Stephan

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

Re: [OSM-dev] How did Mapquest do the localized rendering schemes?

[Stephan Knauss]

On 27.12.2011 12:05, ikonor wrote:

I don't know about the rendering process, but the Mapnik styles are
available at Github [1] and there are three different styles for US, UK
and EU.


Thanks for the pointer to the styles. Any Idea how they determine which 
style to use for which geometry?
I did not see anything that looks like a way to select the one style or 
the other based on the geographic location.


Can you do the location check while rendering or would it be a 
preprocessing step during import? I did not see an additional region 
column so no idea how the selection was done.


Stephan

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

[OSM-dev] How did Mapquest do the localized rendering schemes?

[Stephan Knauss]

Hi,

the featured image shows a mapquest rendering that applies different 
styles based on the region.


As it has the same font problem than mapnik I assume it's mapnik.

How did they do the localization? Adding a boundary check to every way 
query? Sounds expensive. Also the rendering rules would explode if 
applied to a lot of regions.


Is it documented somewhere how they did it?

Stephan


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

[OSM-dev] osm2pgsql does not remove deleted nodes

[Stephan Knauss]

Hi,

I have a problem that when applying diffs a deleted node is not removed.

I think in general it worked fine. Now I have a specific node that can 
not be deleted.


I'm using rev 26385
osm2pgsql SVN version 0.70.5

Calling with these options
osm2pgsql -v -S default.style -s -a --hstore-all -b 
97.3,5.6,109.6,23.4 -U osm -d osm -e 16 -o expire.list change.osc


with this reduced change file:
?xml version='1.0' encoding='UTF-8'?
osmChange version=0.6 generator=Osmosis 0.38
  delete
node id=891306598 version=5 timestamp=2011-09-09T22:04:42Z 
uid=104414 user=Willi2006 changeset=9258444 lat=16.417618 
lon=102.8032077/

  /delete
/osmChange


There is no unusual message in the program output. But later there is 
still the node in the database:
echo SELECT osm_id FROM planet_osm_point WHERE osm_id=891306598 | psql 
-U osm -d osm

  osm_id
---
 891306598
(1 row)


Any idea what's wrong here?


Stephan

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

Re: [OSM-dev] osmosis diff

[Stephan Knauss]

Hi,

On 08.09.2011 00:21, BG wrote:

I use osmosis because of the diff imports.
I do not have the complete planet in my database. only 3 countries.
While making a diff import, does osmosis only update my countries or
does it change every data of the planet?


in a later post you mentioned using mapnik. I suppose you are importing 
into a pgsql database with a mapnik schema.

So you are applying diffs with osm2pgsql.

For that tool it can work with bounding boxes but as ways and relation 
diffs have no geometry they will all go into the database. You have to 
get rid of these regularly.


I'm doing this with a cronjob calling a cleanup query.
http://wiki.openstreetmap.org/wiki/User:Stephankn/knowledgebase#Cleanup_of_ways_outside_the_bounding_box


If you really asking about osmosis: Sorry I have never used it to update 
a database, only updating full planet files.


Stephan

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

Re: [OSM-dev] osmjs -- before_* and after_* are not called?

[Stephan Knauss]

Martijn van Exel writes: 


BTW, is it already possible to use osmium for full history files?
Yes, works fine. I used it to preprocess data for the Where did you Edit. 


Stephan

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

[OSM-dev] How to update a full-history planet file

[Stephan Knauss]

Hi,

what tools do currently exist to keep a full history planet updated?

http://wiki.openstreetmap.org/wiki/Planet.osm/full
talks mysteriously about some osmosis operations that seam to work.

The task I'm looking for is simple. I have the full history planet as 
pbf, want to apply all diffs (let's use hourly-replication (--rri) as 
it's a full history stream) and write out a pbf again.


first thing lacking seams to be support for HistoricalInformation in 
the --read-pbf task.


Peter Körner mentioned at SotmEU that currently no tool exists and 
osmium could be used to create such a tool.
Does this still apply or has someone written a diff application tool 
that can handle full history files?


osmconvert seams to be able to process history files as well as apply 
diffs to them. But it can not write pbf. So the rest of my tools can not 
work with the files. and 500GB .osm XML is no fun to process.


Is there any alternative to using the xml format?

Stephan


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

Re: [OSM-dev] Ways

[Stephan Knauss]

On 11.08.2011 19:29, ant wrote:

So have they been removed from the database then? Or could remnants of
that still exist in recent planet files?


we had a similar discussion a while ago. I had deleted all ways with 
zero nodes in 2280280. But nothing prevents it from happening again.


you might want to take a closer look at the following single-node roads

115480503;{927077425};{highway,service};f
65066578;{165341975};{tiger:zip_right,93117,tiger:zip_left,93117,tiger:tlid,108600206:108658882:108658883:108600207:108637755:108637756:108694096:108694097:108616067:108658910:108658911,tiger:source,tiger_import_dch_v0.6_20070809,tiger:separated,no,tiger:reviewed,no,tiger:name_type,Ave,tiger:name_base,Hollister,tiger:county,Santa 
Barbara, CA,tiger:cfcc,A41,name,Hollister Avenue,highway,secondary};f

120625379;{1156695728};{boundary,administrative,admin_level,9};f
121986178;{248112130};{ref,N5,oneway,yes,name,Grand Trunk 
Road,highway,trunk};f

114673790;{1298398898};{leisure,playground};f
91926284;{232729117};;f
31431630;{31036070};{oneway,yes,lanes,2,highway,unclassified};f
37523138;{27271476};{postal_code,14467,name,Charlottenstraße,highway,residential};f
40678595;{426710103};{highway,residential};f
57040799;{561295573};;f
28067272;{301680368};{name,Kartuska,highway,tertiary};f
5928641;{1357781627};{name,Station Road,maxspeed,30 
mph,highway,tertiary};f
5931991;{21746898};{name,Saint Mary's 
Lane,layer,1,highway,tertiary,bridge,yes};f

62221337;{301685715};{highway,residential};f
4077762;{282699168};{oneway,yes,name,Kings 
Road,junction,roundabout,highway,secondary};f

23575904;{60299249};{ref,A8,highway,motorway};f
30130443;{332028756};{building,yes,addr:housenumber,38};f
62396944;{301974494};{highway,cycleway,foot,yes};f
25943351;{60429906};{name,Gonzagagasse,maxspeed,30,highway,residential};f
35323821;{413584590};{oneway,yes,name,Werdertorgasse,maxspeed,30,highway,residential,cycleway,opposite};f
118338387;{1274530387};{highway,unclassified};f
7391156;{45799341};{name,Vrouwenakker,maxspeed,50,highway,primary};f
7391168;{45801307};{ref,N231,name,Bioklandse 
Weg,maxspeed,50,highway,primary};f

7367843;{45816994};{name,Amstelstraat,highway,unclassified};f
91958189;{370154083};{ref,Y 611,name,Trafikgatan,highway,secondary};f
122190885;{1366136899};{building,yes};f
33922842;{53358969};{name,Oyther 
Straße,highway,secondary,fixme,ungenaue Grenze, bitte verifizieren 
und 
korrigieren,cycleway,track,boundary,administrative,bicycle,yes,admin_level,10};f

120547409;{598559738};{ref,BR040,name,BR-040,layer,1,highway,trunk,bridge,yes};f
29722147;{327434089};{service,parking_aisle,highway,service};f
29722148;{327434097};{service,parking_aisle,highway,service};f
26957057;{25071};{tunnel,no,railway,subway,layer,2};f
41887875;{184669859};{tiger:zip_right,49048,tiger:zip_left_1,49001,tiger:zip_left,49048,tiger:upload_uuid,bulk_upload.pl-1429abda-2e4b-4944-a220-d33e611e51f2,tiger:tlid,12232005,tiger:source,tiger_import_dch_v0.6_20070813,tiger:separated,no,tiger:reviewed,no,tiger:name_type,Hwy,tiger:name_base_1,State 
Highway 96,tiger:name_base,King,tiger:county,Kalamazoo, 
MI,tiger:cfcc,A31,ref,BL I-94,name,King Hwy,highway,primary};f

103157010;{164426180};{maxspeed,10,highway,residential};f
112511879;{1278585509};;f
120839657;{1353931007};{width,4,oneway,yes,name,Noordstraat,highway,residential};f
36956223;{429711325};{name,GR 6,highway,path};f
120948653;{250584632};{name,Rostocker 
Heide,landuse,forest,addr:street,Warnemünder 
Straße,addr:postcode,18146,addr:country,DE,addr:city,Rostock-Markgrafenheide};f
30248773;{361756};{ref,B 
2,name,Bodenseestraße,maxspeed,50,highway,primary};f

11846706;{106305180};{railway,rail};f
13330920;{1316706198};{tiger:zip_right,92802,tiger:zip_left,92802,tiger:upload_uuid,bulk_upload.pl-96b38365-dd2d-4eab-8ec1-33441607e7c5,tiger:tlid,144254323:144254324:144254334,tiger:source,tiger_import_dch_v0.6_20070809,tiger:separated,no,tiger:name_type,Ave,tiger:name_direction_prefix,S,tiger:name_base,Manchester,tiger:county,Orange, 
CA,tiger:cfcc,A41,oneway,yes,name,Disney Way,highway,secondary};f

122302406;{423176408};{psv,designated,motorcycle,no,motorcar,no,highway,unclassified,hgv,no,bicycle,no};f
121932324;{1363705874};{name,Howdens Hill,highway,tertiary};f
52737109;{334244148};{uploaded_by,Wolfgang W. 
Wasserburger,plan_at:acad_id,wz2464,name,Schubertgasse,is_in,Weiz,Weiz,Steiermark,Österreich,Europe,highway,residential,fixme,check 
import,at:maxspeed,Ortsgebiet,addr:postcode,8160};f

52737110;{348228707};{name,Schubertgasse,is_in,Weiz,Weiz,Steiermark,Österreich,Europe,highway,residential,addr:postcode,8160};f
24574031;{1368371931};{oneway,yes,name,Remízková,highway,residential};f
39665829;{415334903};{ref,D 
39,highway,secondary,bridge,yes,boundary,administrative,admin_level,8};f

118600200;{1333624963};;f
82698598;{104977310};{ref,C-2,oneway,yes,old_name,William Cameron 
Forbes,name,Arsenio H. Lacson 
Avenue,maxspeed,60,lit,yes,history,retrieved using undelete JOSM 

Re: [OSM-dev] osm2pgsql, zoom range for -e option?

[Stephan Knauss]

Hi Markus,

On 09.08.2011 19:53, mar...@gmx.eu wrote:

OK, I fixed the bug. - If it really was a bug and not intended behaviour.
I'm still not sure...

My patch (I added just 2 lines):
diff -C 5 -p expire-tiles_old.c expire-tiles.c
--- 139,151 
+   if(this_zoom=min_zoom)
+   fprintf(outfile, %i/%i/%i\n, this_zoom, x, y);
+


I would also expect the lowzoom tiles being expired. Having a quick look 
at the source I don'T understand both. What do you try to fix with this 
patch?


If the tile is dirty, I guess it would match one of the tree-complete 
conditions.


What is the flow? It looks like it is recursing by increasing the zoom 
level. So it would have started at the low-zooms already. Why did it not 
output anything in this situation?


Is the _mark_tile() working as expected? Do you have data to reproduce 
the problem?


Stephan

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