00:00:16 <Spone> thanks I will try that out tomorrow
00:00:23 <Spone> have a good night :)
00:02:50 *** haoyu (~bhy@cm144.delta24.maxonline.com.sg) has joined #mapnik
00:08:33 *** tcarobruce has quit (Quit: tcarobruce)
00:17:02 *** springmeyer (~springmey@209.133.114.31) has joined #mapnik
00:17:44 *** tcarobruce (~tim@209.133.114.31) has joined #mapnik
00:20:05 *** c_lopez (~ccaarloos@189.161.104.92) has joined #mapnik
00:20:41 <c_lopez> hello everyone
00:20:53 <c_lopez> hi Mr. Springmeyer, how are you?
00:21:14 <springmeyer> hey, hello carlos!
00:21:38 <springmeyer> I'm good. so so tired as I've been talking to many people here at Where2.0 conference
00:21:38 *** tcarobruce has quit (Client Quit)
00:21:44 <springmeyer> but it is going great
00:22:46 <c_lopez> great! are you giving a conference? I saw in the website of Where 2.0 that one of the highlights was OSM.
00:23:03 *** ajturner has quit (Quit: ajturner)
00:23:19 <springmeyer> no, I am just here to meet and discuss
00:24:01 <springmeyer> this talke:
00:24:05 <springmeyer> talk I mean
00:24:07 <springmeyer> http://developmentseed.org/blog/2010/mar/31/can-moving-open-data-cloud-help-accessibility
00:24:11 <springmeyer> is beginning now...
00:24:50 *** tcarobruce (~tim@209.133.114.31) has joined #mapnik
00:26:58 <c_lopez> wow, it seems interesting, although I'm not very familiar with the concept of the 'cloud'.
00:30:17 *** ajturner (~ajturner@209.133.114.31) has joined #mapnik
00:31:45 <c_lopez> Mr. Springmeyer, can I ask you a question about the Better Print Support project?
00:31:58 <springmeyer> c_lopez: yes yes
00:37:15 <c_lopez> well, I realize that Mr Pavlenko's idea of implementing an SVG renderer is very different from the ones that others, including you, are thinking of, so I would like to ask you which would be the main goal of the project, the SVG renderer or the improvements in resolution and the other related things, which seem to be closer to what the name of the project suggest.
00:40:28 *** Spone has quit (Quit: Page closed)
00:41:35 <springmeyer> c_lopez: yes, I think his idea raises a core question
00:41:48 <springmeyer> is the end goal (or at least primary goal)...
00:42:01 <springmeyer> better printable output, directly from mapnik
00:42:26 <springmeyer> or is the primary goal better output to enable post-processing
00:42:40 <springmeyer> or viewing in a PDF viewer, etc
00:43:02 <springmeyer> my feeling is that both are very valuable
00:43:25 <springmeyer> and also share many concepts, and some tasks
00:44:08 <springmeyer> but you are quite right, that the SVG renderer would be more distinct, and different
00:45:10 <springmeyer> and I don't feel like doing it all is possible
00:45:38 *** wallyqs (invertedpl@189.161.104.92) has joined #mapnik
00:45:59 *** jctull has quit (Quit: jctull)
00:46:25 <springmeyer> so one approach could be to
00:46:34 <c_lopez> I also think it would be too ambitious
00:46:41 <springmeyer> yes
00:47:01 <springmeyer> or, perhaps other items would be smaller and more rewarding
00:47:30 <springmeyer> a potential approach could be:
00:48:19 <springmeyer> identify top 3 items that cut across all issues
00:48:26 *** ajturner has quit (Quit: ajturner)
00:49:13 <springmeyer> that would be needed and usefull (or at least related to) all idea mentioned
00:50:46 <springmeyer> and commit to those
00:51:25 <springmeyer> so the evaluations are able to be done on clearly defined, feasible, and fun pieces of Mapnik development
00:51:31 <c_lopez> variable resolution would be one of the core ideas I think
00:51:46 <springmeyer> yes, that is my feeling
00:52:01 <springmeyer> and it seems pretty easy to implement
00:52:13 <springmeyer> but I would imagine that as you get down to coding and testing
00:52:28 <springmeyer> many interesting issues may arise even with that
00:52:59 <springmeyer> and then variable units, and scalable raster symbols are the two others that come to my mind
00:53:40 <c_lopez> I understand, based on ticket 343, that variable resolution would be provided directly from the core classes (map, for instance), so the mechanism would be reusable across the different renderers, right?
00:53:41 <nikq> Ticket #343: Add a resolution parameter to Map object, http://trac.mapnik.org/ticket/343
00:54:14 <springmeyer> yes, it should be reusable across renderers, exactly
00:54:29 <springmeyer> but does not necessarily need to be a property of the map object
00:55:10 <springmeyer> for example, perhaps if it were an argument of mapnik.render() then it might be more flexible
00:55:25 <springmeyer> also, perhaps applying one global scaling factor is not cool enough
00:55:57 <springmeyer> but rather different scaling factors could be useful so different types of map features could be scaled differently
00:56:50 <springmeyer> c_lopez: these are ideas, and could be a very fun combination of coding, writing tests, and showing examples to the community to get feedback on the interesting things people are hoping to do
00:57:55 <springmeyer> c_lopez: I would be interested to know your thinking about other "cross-cutting" or core ideas that have come up
00:58:08 <c_lopez> is this scaling factor you are referring to  the one used in feature_style_processor (called scaling denominator, I think)?
00:58:30 <springmeyer> I think you are doing a really great job researching so I'm sure you'll have good idea
00:58:48 <springmeyer> no c_lopez it is different, but related of course
00:59:10 <springmeyer> the "scaling_factor" I am thinking of is the one in the basic patch in #343
00:59:11 <nikq> Ticket #343: Add a resolution parameter to Map object, http://trac.mapnik.org/ticket/343
00:59:43 <springmeyer> a factor applied to things like symbolizer stroke width and font size
00:59:50 *** ajturner (~ajturner@209.133.114.31) has joined #mapnik
01:00:17 <springmeyer> and the tricky/fun issue is how that may interact with the map zoom level (which is what the scale_denominator is about)
01:01:34 *** ajturner has quit (Client Quit)
01:02:07 <springmeyer> the 'scale_denominator' handles the relationship between units in the map image and in the real world
01:02:11 <springmeyer> http://trac.mapnik.org/browser/trunk/src/scale_denominator.cpp
01:02:20 <springmeyer> I understand if it is confusing :)
01:03:44 <springmeyer> I also forgot #196, which should likely be investigated along with #343
01:03:44 <nikq> Ticket #343: Add a resolution parameter to Map object, http://trac.mapnik.org/ticket/343
01:03:51 <c_lopez> oh ok, then I think it is important for me to keep working on those tickets, I'm starting to see that some of them are related closely
01:05:36 *** tcarobruce has quit (Quit: tcarobruce)
01:05:53 <nikq> Mapnik Trac: Ticket #196 (Support dynamic pixels) updated | http://trac.mapnik.org/ticket/196#comment:5
01:06:44 <nikq> Mapnik Trac: GSOC2010/Ideas edited | http://trac.mapnik.org/wiki/GSOC2010/Ideas?version=15
01:08:40 <rweait>  What's the trick to rendering a large image "just like the OSM web site" in terms of zoom level, and lat/lon bounding boxes?  Where does dpi fit in?  Is something-nik better than generate_image.py for this?
01:09:10 <rweait> I know this is an FAQ.  I'm lame.
01:12:51 <c_lopez> thanks Mr. Springmeyer for your answers, I'll post to the mailing list as soon as I have something.
01:26:06 *** springmeyer has quit (Quit: springmeyer)
01:31:24 *** wallyqs has parted #mapnik (None)
01:43:58 *** mperry has quit (Ping timeout: 260 seconds)
01:54:31 *** c_lopez has parted #mapnik (None)
02:00:09 *** c_lopez (~ccaarloos@189.161.104.92) has joined #mapnik
02:26:19 *** tcarobruce (~tim@209.133.114.31) has joined #mapnik
02:28:00 *** tcarobruce has quit (Client Quit)
03:12:12 *** c_lopez has parted #mapnik (None)
03:24:26 *** jctull (~jctull@adsl-75-0-29-113.dsl.renocs.sbcglobal.net) has joined #mapnik
03:58:15 <hesco> using TIGER data, which shape files would provide me with the street names?
04:01:32 <hesco> also, where might I find style definitions which could produce a map like what is available at: http://www.maposmatic.org/ .
04:24:10 <rweait> hesco: I believe that maposmatic publishes all of their materials.
04:25:31 <rweait> hesco, from maposmatic: "For the map rendering, we use the famous Mapnik with the OpenStreetMap stylesheet available in OpenStreetMap Subversion repository. Using Mapnik and Cairo, we built OCitySMap, a Python module that: "
04:25:59 <rweait> http://www.maposmatic.org/about/
04:26:55 *** c_lopez (~ccaarloos@189.169.36.17) has joined #mapnik
04:33:47 <hesco> thanks, I'll look closer at that.  What about street names?  Are they to be found among the shape files which TIGER provides?
04:34:02 <hesco> If not, is there a free source for those?
06:00:37 *** c_lopez has quit (Ping timeout: 264 seconds)
06:33:28 *** kredik has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.2/20100316074819])
07:56:28 *** rweait has quit (Ping timeout: 252 seconds)
09:31:00 *** gavinf has quit (Read error: No route to host)
09:51:45 *** josias (~d469dc41@gateway/web/freenode/x-othkylkiozeztczo) has joined #mapnik
10:00:39 *** Genscher (~Richard@dslb-088-067-170-191.pools.arcor-ip.net) has joined #mapnik
10:00:39 *** RichardsDesk_ (~Richard@dslb-088-067-170-191.pools.arcor-ip.net) has joined #mapnik
10:00:39 *** RichardsDesk_ has quit (Client Quit)
10:47:55 *** dodobas has quit (Read error: Operation timed out)
10:57:49 *** dodobas (~dodobas@open.geof.hr) has joined #mapnik
11:08:12 *** HounD (~HounD@unics1.grfc.ru) has joined #mapnik
11:33:59 *** rweait (~nerd@weait.tor.istop.com) has joined #mapnik
11:34:51 *** Genscher has quit (Quit: Leaving)
11:41:46 *** luneff (~yury@93.178.95.97) has joined #mapnik
12:03:28 *** josias has quit (Ping timeout: 252 seconds)
13:11:48 *** luneff has quit (Quit: Leaving)
13:31:24 *** Genscher (~Richard@dslb-088-067-170-191.pools.arcor-ip.net) has joined #mapnik
13:42:05 *** willwhite (~diggersf@c-98-218-226-144.hsd1.dc.comcast.net) has joined #mapnik
13:47:16 *** harobed (~stephane@pda57-1-82-231-115-1.fbx.proxad.net) has joined #mapnik
14:12:17 *** HounD has quit (Ping timeout: 265 seconds)
14:12:18 *** msimard (~msimard@modemcable149.77-21-96.mc.videotron.ca) has joined #mapnik
15:21:00 *** c_lopez (~ccaarloos@189.169.36.167) has joined #mapnik
15:30:22 <msimard> I have an EPSG:900913 that renders correctly using mapnik...but when I try to use tilecache+mapnik there are missing geometries or incorrect ones...I'm desperate for help! héhé
15:37:16 *** chad_burt has quit (Quit: Leaving...)
15:37:24 *** chad_burt (~chad_burt@mm-01.msi.ucsb.edu) has joined #mapnik
15:49:29 *** c_lopez has parted #mapnik (None)
15:49:37 *** c_lopez (~ccaarloos@189.169.36.167) has joined #mapnik
15:59:18 <c_lopez> good morning! Does anyone know if agg_renderer or cairo renderer currently support vector output?
16:13:52 *** cgs_bob has quit (Ping timeout: 268 seconds)
16:15:03 *** jctull has quit (Quit: jctull)
16:15:48 *** harobed has quit (Quit: Ex-Chat)
16:21:01 *** c_lopez has quit (Ping timeout: 264 seconds)
16:25:30 *** xreal (~mweber@mailgw.FB12.Uni-Dortmund.DE) has joined #mapnik
16:25:50 <xreal> MMh, why does osm2pgsql create indixes BEFORE adding data?
16:26:07 <xreal> I've benchmarked it on osmosis - building them AFTER import is much faster.
16:26:44 <xreal> Even if it is primary key
16:33:10 *** jctull (~jctull@adsl-75-0-4-106.dsl.renocs.sbcglobal.net) has joined #mapnik
16:33:24 *** mperry (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik
16:47:17 *** tcarobruce (~tcarobruc@adsl-75-10-247-30.dsl.pltn13.sbcglobal.net) has joined #mapnik
16:47:34 *** msimard has quit (Quit: Ex-Chat)
16:57:00 *** cgs_bob (~bob@60.sub-75-210-117.myvzw.com) has joined #mapnik
16:59:10 *** c_lopez (~ccaarloos@189.169.36.167) has joined #mapnik
17:00:57 <c_lopez> Does anybody know if mapnik is capable of displaying legends? Like in http://trac.mapnik.org/wiki/Legending. From this article it seems it doesn't, but it seems to me like a nice feature to have.
17:03:41 <c_lopez> oh, there's a ticket already.
17:14:31 *** Genscher has quit (Quit: Leaving)
17:22:36 *** c_lopez has quit (Ping timeout: 245 seconds)
18:00:28 *** dkb has quit (Quit: Leaving.)
18:00:48 *** c_lopez (~ccaarloos@189.169.36.167) has joined #mapnik
18:11:39 *** dkb (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik
18:14:44 *** dkb1 (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik
18:16:18 *** userRr__ (~userRr@84.123.159.210.dyn.user.ono.com) has joined #mapnik
18:16:21 <userRr__> Hi
18:16:32 <userRr__> C or C++? :-O
18:17:50 *** dkb has quit (Ping timeout: 268 seconds)
18:22:55 *** ajturner (~ajturner@209.133.114.31) has joined #mapnik
18:26:22 <xreal> dkb: are you here?
18:26:27 <dkb1> yes
18:26:48 <xreal> dkb1: I've done some automatic testing this night with importing Germany.
18:27:00 <xreal> Importing everything into hstore is only 11% bigger than normal scheme!
18:27:28 <xreal> And it's even FASTER since there are no string comparisms.
18:28:20 <xreal> For the next tests, I'll put the tablespace into RAM
18:28:23 <userRr__> more fast? c++ or c??
18:28:40 <xreal> userRr__: I'm talking about hstore importing ;-)
18:28:47 *** Ldp__ (~thid@osm.xs4all.nl) has joined #mapnik
18:29:07 <userRr__> u.u
18:33:56 <xreal> Is it normal after updating osm2pgsql-scheme with osmosis that there are double or triple entries?
18:35:40 <dkb1> probably best to ask on the #osm irc?
18:36:43 <xreal> I thought here were the osm2pgsql developers?
18:36:52 <Ldp__> xreal: wondering about the sequence of events there. You cannot update an osm2pgsql schema with osmosis
18:37:24 <xreal> Ldp__: Sure ... it's the normal way for minute mapnik.
18:37:37 <xreal> osm2pgsql --small
18:37:46 <Ldp__> that's not osmosis
18:37:53 <xreal> No, but osm2pgsql small scheme.
18:37:58 <Ldp__> slim :)
18:38:10 <xreal> whatever ;-)
18:38:13 <Ldp__> osmosis --rri -wxc | osm2pgsql -a -s
18:38:17 <xreal> I'm using replicants: osmosis --rri
18:38:45 <Ldp__> you might want to do osmosis --rri --wxc --simc | osm2pgsql -a -s
18:38:59 <xreal> Yes, that's what I am doing. Oh wait, what is --simc ?
18:39:03 <Ldp__> simc = simplify changes, keeps only the latest version in the changes. Otherwise there could be more than 1 version in there
18:39:07 <xreal> ohhhhh
18:39:11 <xreal> ohhhhhhhhh
18:39:23 <xreal> It has _never_ been written down anywhere, has it?
18:39:30 <Ldp__> I've been running without --simc for a very long time, and I had no problems that I could see
18:39:46 <xreal> http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#--simplify-change_.28--simc.29
18:39:48 <xreal> Oh, there it is.
18:40:15 <xreal> Ldp: Are you updating it via osm2pgsql now?
18:40:27 <Ldp__> xreal: the information is fragmented between the wiki, mailing list posts, irc
18:40:39 <Ldp__> I'm doing what I wrote before
18:40:49 <xreal> Ldp: Ah okay ;-)
18:41:06 <dkb1> Ldp_: so should the normal update of changes always use -simc?
18:41:36 <Ldp__> if you are rendering, sure, to be safe
18:41:45 <Ldp__> you only want to render the latest version anyway
18:41:59 <dkb1> What happens if I haven't been doing that? i.e. time osm2pgsql -a -s -U mapper -S ./default.style -d gis -C 3000 ../.osmosis/change.osc
18:44:00 * xreal is dropping his DB and trying again
18:44:38 <xreal> dkb1: I can try it for you, if you want?
18:45:12 <dkb1> xreal: sounds like I'm going to have to re-import the planet anyways.
18:45:30 <dkb1> comes out today, not sure what time
18:47:12 <xreal> dkb1: But perhaps it's better for you to know, if osmosis import or osm2pgsql import works better and/or faster.
18:47:42 <xreal> dkb1: hstore import will get fixed over the holidays. It's crashing when importing the planet. Problem is a hardcoded value, as always.
18:49:17 *** haoyu has quit (Ping timeout: 276 seconds)
18:49:38 <dkb1> I'm sticking with osm2pgsql for import
18:51:22 <xreal> dkb1: How do you compile the changefiles ?
18:52:21 <dkb1> xreal: according to the bottom of this page: http://wiki.openstreetmap.org/wiki/Minutely_Mapnik
18:52:51 <dkb1> which I am about to fixup, especially for the mention of -simc
18:54:15 <xreal> dkb1: That was the first report about 1 minute changefiles ever ... I think that is the oldest solution.
18:55:03 <Ldp__> xreal: no, there's 2 parts to that wiki page. The stuff at the bottom is the current stuff
18:56:09 *** userRr__ has parted #mapnik ("Saliendo")
18:57:02 <dkb1> *and notes the info is from Ldp on the bottom of page :) *
18:59:10 <dkb1> Ldp: do you mind if that is cleaned up a bit? especially since the "wrong URL" is corrected in osmosis
19:01:37 <xreal> Ldp: So there is no --simc? It isn't even working here ;-)
19:02:29 <xreal> "No default pipes are available as input for task 3-simc."
19:03:30 <Ldp__> dkb1: it's a wiki, go ahead
19:03:50 <Ldp__> --simc works on a change stream. What's your osmosis incantation?
19:04:19 <xreal> Ldp__: Wait, Putty makes trouble.
19:05:11 <xreal> osmosis --rri --wxc --simc | osm2pgsql --append --slim --cache 1000  --hstore --merc --style /osm/hstore.style --host 127.0.0.1 --database test --user osm --verbose -
19:05:26 <xreal> "osmosis --rri --wxc --simc changes.osc" also doesn't work.
19:05:35 <Ldp__> update your osmosis?
19:05:38 <xreal> 0.34
19:05:45 <Ldp__> should work
19:06:01 <xreal> Actally, --simc is existing, but it seems to want an input ?
19:06:27 <Ldp__> my bad, change it to --rri --simc --wxc
19:06:56 <xreal> Wow; I didn't that know the order is important
19:07:22 <Ldp__> it's very important
19:07:32 <xreal> Okay, noted down to my textfile!
19:08:02 <xreal> BTW: I've just ordered a ASUS Eee PC T101MT !!
19:08:10 <xreal> Mapping will be much more fun then.
19:08:18 <xreal> Multitouch Netbook (convertible)
19:08:38 <dkb1> *iPad arriving here :) *
19:09:00 <xreal> dkb1: My updates will be free.
19:10:27 <xreal> Ldp__: Doesn't work: "The following named pipes () and 1 default pipes have not been terminated with appropriate output sinks."
19:11:11 <dkb1> xreal: what is your entire command now?
19:12:16 <Ldp__> --rri outputs a change stream. --simc read/writes a change stream. --wxs reads a change stream and writes a file/pipe. Should work as --rri --simc --wxc
19:12:22 <Ldp__> --wxc
19:13:04 <xreal> Oh, "osmosis --rri --wxc --simc changes.osc" doesn't work, but "... | osm2pgsql -a" seems to work
19:13:17 <Ldp__> xreal: wrong order
19:13:17 <xreal> sorry, I mean "osmosis --rri --simc --wxc"
19:13:21 <Ldp__> yeah
19:13:31 <xreal> Last one gives me an error again.
19:13:48 <Ldp__> of course, you need to add a file or a |
19:14:01 <xreal> Yep, I gave a dir of course.
19:14:07 <xreal> Oh, osm2pgsql said: "Entity: line 1: parser error : Extra content at the end of the document"
19:14:08 <Ldp__> file != dir
19:14:17 <Ldp__> so either osmosis --rri --simc --wxc changes.osc, or osmos --rri --simc --wxc | osmosis -a
19:14:23 <xreal> --rri workingDirectory=.
19:14:30 <xreal> with a file
19:14:37 <xreal> oh wait, let me copy the complete line ;-)
19:14:44 <xreal> It wraps at the small ssh window.
19:14:49 <dkb1> Ldp: osmosis defaults to changes.osc if you don't specify it
19:15:10 <Ldp__> dkb1: ok, didn't know. I never write interim files during minutely updates
19:15:14 <xreal> This doesn't work: osmosis --rri workingDirectory=. --simc --wxc change.osc
19:15:43 *** c_lopez has quit (Ping timeout: 252 seconds)
19:16:28 <xreal> Funny, NOW it works ;-)
19:16:37 <xreal> I just retyped it.
19:16:40 <dkb1> that line worked for me
19:16:59 <xreal> Seems like some UTF8 char was between it.
19:18:06 <xreal> Wow, it's 26 MB smaller than the non-simplified changefile!
19:18:53 <dkb1> Ldp: what use case you would want the multiple changes to be left in (besides someone interested in history)?
19:19:50 <Ldp__> exactly, when you're feeding --rri into an osmosis simple schema database with history
19:20:12 <Ldp__> in all other cases, all but the latest version are uninteresting
19:20:48 <xreal> The problem is in planet_osm_line there is no possibility to identify the last version.
19:21:01 <xreal> I've got three identical entries, only (way) is different.
19:21:34 *** Genscher (~Richard@dslb-188-098-005-084.pools.arcor-ip.net) has joined #mapnik
19:21:43 <Ldp__> xreal: shouldn't actually happen. Every time osm2pgsql encounters another occurence of the same osm id in the OSC file, it would update the previous
19:22:02 <xreal> Ldp__: Perhaps osm2pgsql is fooling me today?
19:22:14 <Ldp__> so in your case, it would be processing that additional 26MB for no reason, but the end result should be the same
19:22:29 <Ldp__> I don't know. I know a lot about it, but definately not all
19:22:40 <xreal> Ldp__: Perhaps it's an issue with hstore?
19:22:56 <Ldp__> xreal: I wouldn't discount that possibility
19:23:06 <xreal> Okay, let me do some more testing.
19:23:32 <xreal> Did you read about my import of Germany? It's only 11% bigger with all the tags than "normal" amount of tags.
19:23:42 <xreal> it's even faster.
19:23:45 <Ldp__> I haven't read the MLs yet
19:24:02 <xreal> I didn't publish it there, since hstore isn't much tested right now.
19:24:06 <xreal> it's crashing when importing the planet.
19:24:12 <xreal> Might be some hardcoded variable.
19:24:13 <Ldp__> xreal: but I'm not too surprised. The geom objects take up most of the space, tags are small
19:25:16 <xreal> hstore saves me a lot of time: I don't need osmosis schema anymore.
19:30:19 <Ldp__> good, so no more need to keep 2 separate databases uptodate
19:30:30 <Ldp__> in many cases
19:32:12 <xreal> Again the same problem ...
19:32:24 <xreal> 3 equal IDs in planet_osm_line
19:32:31 <xreal> two with geom, one without
19:32:42 <Ldp__> with --simc?
19:34:37 <xreal> yep
19:34:54 *** c_lopez (~ccaarloos@189.169.36.167) has joined #mapnik
19:34:54 *** c_lopez has parted #mapnik (None)
19:35:02 *** c_lopez (~ccaarloos@189.169.36.167) has joined #mapnik
19:35:03 <xreal> That's why I did an intermediate file ;-)
19:35:06 <xreal> let me check this one.
19:35:10 <Ldp__> so, write to changes.osc, check the contents for duplicate objects, and only then feed it separately to mapnik -a ?
19:35:29 <Ldp__> if it still happens, definately something in osm2pgsql different with the hstore addition
19:36:25 <Ldp__> at a guess: those 2 with a geom are the objects before and after the change and the one without geom is another bug?
19:37:51 <xreal> another questions: why are there NEGATIVE IDs?
19:38:06 <xreal> Ldp: Don't know, but I can check it after the next import.
19:39:40 <xreal> Funny, "-62644" isn't in this changefile at all!
19:39:52 <xreal> Let me reimport the extract.
19:41:04 <Ldp__> negative id = relation
19:41:34 *** c_lopez has quit (Ping timeout: 252 seconds)
19:42:39 <xreal> Ldp__: Confusing somehow.
19:45:28 <xreal> Oh, "Independence Day" will be continued.
19:47:03 <xreal> I am legend(ary stupid).
19:52:43 *** ajturner has quit (Quit: ajturner)
19:53:38 <xreal> verrrrry interesting: it's already inside of the planet extract!
19:55:31 <xreal> Let me import it without hstore.
19:59:01 *** c_lopez (~ccaarloos@189.169.36.167) has joined #mapnik
20:00:25 <xreal> Ldp__: Same problem without hstore.
20:00:31 <xreal> How is that possible at all?
20:01:32 <xreal> A damaged relation perhaps?
20:04:02 <xreal> Yes, it has to be a damaged relation.
20:04:11 <xreal> It's at the border of the extract.
20:05:50 <xreal> Funny, ST_AsText(way) gives a result on the empty geom, ST_AsKML(way) doesn't.
20:17:20 *** luneff (~yury@93.178.95.97) has joined #mapnik
20:40:19 *** willwhite has quit (Quit: willwhite)
20:59:55 *** c_lopez has quit (Ping timeout: 246 seconds)
21:06:26 *** sam` has quit (Read error: Operation timed out)
21:06:44 *** sam` (~sam@glau.bulix.org) has joined #mapnik
21:20:04 *** ajturner (~ajturner@209.133.114.31) has joined #mapnik
21:21:58 *** ajturner has quit (Client Quit)
21:32:28 *** bitterman (~yury@93.178.81.135) has joined #mapnik
21:33:15 *** c_lopez (~ccaarloos@189.169.36.167) has joined #mapnik
21:35:50 *** luneff has quit (Ping timeout: 260 seconds)
21:36:06 *** tomhughes has quit (Ping timeout: 276 seconds)
21:36:09 *** tomhughes (~tom@gosford.compton.nu) has joined #mapnik
21:43:52 *** ajturner (~ajturner@209.133.114.31) has joined #mapnik
21:46:57 *** willwhite (~diggersf@dhcp-234-104.wireless.american.edu) has joined #mapnik
21:51:34 *** cgs_bob_ (~bob@234.sub-75-211-102.myvzw.com) has joined #mapnik
21:51:59 *** cgs_bob has quit (Ping timeout: 276 seconds)
21:52:39 *** Genscher has parted #mapnik ("Leaving")
22:00:31 *** darth_bitterman (~yury@93.178.81.135) has joined #mapnik
22:03:51 *** bitterman has quit (Ping timeout: 245 seconds)
22:17:34 *** jctull has quit (Quit: jctull)
22:29:38 *** willwhite has quit (Quit: willwhite)
22:32:44 *** xreal has quit (Ping timeout: 240 seconds)
22:38:45 *** willwhite (~diggersf@dhcp-234-104.wireless.american.edu) has joined #mapnik
22:44:42 *** ajturner has quit (Quit: ajturner)
22:50:22 *** darth_bitterman has quit (Quit: Leaving)
22:59:39 *** jctull (~jctull@adsl-75-0-29-113.dsl.renocs.sbcglobal.net) has joined #mapnik
23:30:22 *** willwhite has quit (Quit: Leaving)
23:48:08 *** c_lopez has quit (Read error: Connection reset by peer)